Azure - Serviçoes de Aplicações

Contents
Documentação do Serviço de Aplicações

Descrição geral
Acerca das Aplicações Web
Acerca do Serviço de Aplicações no Linux
Acerca dos Ambientes do Serviço de Aplicações
Comparar opções de alojamento
Guias de Início Rápido
Criar aplicação .NET Core
Criar aplicação no .NET Framework
Criar aplicação Node.js
Criar aplicação PHP
Criar aplicação Java
Criar site HTML estático
Executar o contentor do Windows
Tutoriais
Aplicação com BD
.NET Core com BD SQL
.NET Framework com BD SQL
PHP com MySQL
Node.js com MongoDB
Personalizar o Windows (contentor)
Aceder à BD SQL em segurança
Alojar uma API RESTful
Mapear domínio personalizado
Proteger domínio com SSL
Adicionar a CDN
Autenticar utilizadores
Enviar e-mail/tweet
Amostras
CLI do Azure
Azure PowerShell
Modelos do Resource Manager
Incorporações do Azure Policy
Conceitos
Planos do Serviço de Aplicações
Funcionalidade do SO
Melhores práticas de implementação
Segurança
Recomendações
Autenticação e autorização
SO e aplicação de patches do tempo de execução
Controlos de segurança incorporados
Descrição geral da segurança
Funcionalidades de rede
Descrição geral
Gateway de Aplicação com pontos finais de serviço
Ponto Final Privado
IPs de entrada e de saída
Integração da Rede Virtual
Ligações híbridas
Integração do Gestor de Tráfego
Cache local
Diagnóstico
Guias de Procedimentos
Configurar aplicação
Configurar definições comuns
Configurar PHP
Configurar o Java
Ligar a recursos no local
Configurar o Armazenamento do Azure (contentor)
Implementar no Azure
Implementar a aplicação
Executar a partir do pacote
Implementar ZIP ou WAR
Implementar através de FTP
Implementar através da sincronização da cloud
Implementar continuamente
Implementar a partir do Git local
Implementar com o GitHub Actions
Implementar com modelo
Definir credenciais de implementação
Criar ambientes de teste
Modelo do Resource Manager
Comprar domínio
Mapear domínios com o Gestor de Tráfego
Migrar um domínio ativo
Proteger aplicação
Adicionar certificado SSL
Autenticar utilizadores
Autenticar com o Azure AD
Autenticar com o Facebook
Autenticar com o Google
Autenticar com a conta Microsoft
Autenticar com o Twitter
Autenticação avançada
Restringir o acesso
Utilizar uma identidade gerida
Referenciar segredos do Key Vault
Utilizar certificado SSL no código
Configurar a autenticação mútua de TLS
Encriptar dados do site
Dimensionar aplicação
Aumentar verticalmente a capacidade do servidor
Configurar o escalão PremiumV2
Aumentar horizontalmente para várias instâncias
Alojamento de alta densidade
Monitorizar aplicação
Quotas e alertas
Ativar registos
Obter eventos de recursos
Gerir aplicação
Gerir o plano de alojamento
Efetuar cópia de segurança de uma aplicação
Restaurar uma cópia de segurança
Restaurar um instantâneo
Clonar uma aplicação
Restaurar o Serviço de Aplicações eliminado
Mover aplicação
Mover entre regiões
Mover subscrições
Execução de tarefas em segundo plano
Criar Trabalhos Web
Desenvolver Trabalhos Web com o VS
Introdução ao SDK do WebJobs
Utilizar o SDK do WebJobs
Referência
CLI do Azure
Azure PowerShell
API REST
Modelo do Resource Manager
Recursos
Blogue do Serviço de Aplicações
Desenvolva as suas competências com o Microsoft Learn
Mapa do Azure
Preços
Informações sobre a Quota
Atualizações de serviço
Guias do Assistente de Migração
Melhores práticas
Amostras
Vídeos
Cookbooks
Arquiteturas de Referência
Scripts de Implementação
Resolução de problemas
Resolução de erros de ligação de saída intermitentes
Resolver problemas com o Visual Studio
Resolver problemas da aplicação Node.js
Resolver erros de HTTP 502 e 503
Resolver problemas de desempenho
Resolver problemas de domínio e de certificado
FAQ
FAQ sobre disponibilidade, desempenho e aplicações
FAQ sobre implementação
FAQ sobre tecnologias open-source
FAQ sobre configuração e gestão
Alteração de endereço IP
Endereço IP de entrada
Endereço IP de saída
Endereço SSL
Descrição geral do Serviço de Aplicações
01/05/2020 • 6 minutes to read • Edit Online
O Azure App Service é um serviço baseado em HTTP para hospedar aplicações web, APIs REST e back
ends móveis. Pode desenvolver no seu idioma favorito, seja .NET, .NET Core, Java, Ruby, Node.js, PHP ou
Python. As aplicações funcionam e escalam com facilidade tanto em ambientes baseados em Windows
como em Linux. Para ambientes baseados em Linux, veja Serviço de Aplicações no Linux.
O Serviço de Aplicações não só adiciona a potência do Microsoft Azure à sua aplicação, como segurança,
equilíbrio de carga, autoscalcificação e gestão automatizada. Também pode tirar partido das suas
capacidades de DevOps, tais como a implantação contínua da Azure DevOps, GitHub, Docker Hub, e
outras fontes, gestão de pacotes, ambientes de encenação, domínio personalizado e certificados TLS/SSL.
Com o Serviço de Aplicações, paga pelos recursos de computação do Azure que utilizar. Os recursos
computacionais que utiliza são determinados pelo plano de Serviço de Aplicações em que executa as
suas aplicações. Para mais informações, consulte a visão geral dos planos do Azure App Service.
Porquê utilizar o App Service?

Aqui estão algumas funcionalidades chave do Serviço de Aplicações:
Múltiplas línguas e quadros - O App Service tem suporte de primeira classe para ASP.NET,
ASP.NET Core, Java, Ruby, Node.js, PHP ou Python. Também pode executar o PowerShell e outros
scripts ou executáveis como serviços em segundo plano.
Ambiente de produção gerido - O Serviço de Aplicações remende e mantém automaticamente o
SISTEMA e os quadros linguísticos para si. Passe o tempo escrevendo grandes apps e deixe o Azure
preocupar-se com a plataforma.
Otimização de DevOps – Configure a integração e implementação contínuas com o Azure DevOps,
GitHub, BitBucket, Docker Hub ou Azure Container Registry. Promova atualizações através de
ambientes de teste. Faça a gestão das suas aplicações no App Service utilizando o Azure PowerShell
ou a interface de linha de comandos (CLI) de várias plataformas.
Dimensionamento global com elevada disponibilidade – aumente verticalmente ou
horizontalmente de forma manual ou automática. Aloje as aplicações em qualquer lugar da
infraestrutura do datacenter global da Microsoft e o App Service SLA promete elevada
disponibilidade.
Ligações a plataformas SaaS e dados no local – escolha entre mais de 50 conectores para
sistemas empresariais (como SAP), serviços SaaS (como o Salesforce) e serviços Internet (como o
Facebook). Aceda a dados no local ao utilizar Ligações Híbridas e Azure Virtual Networks.
Segurança e conformidade – o App Service está em conformidade com ISO, SOC e PCI. Autentique
os utilizadores com o Azure Active Directory ou com início de sessão social (Google, Facebook, Twitter
e Microsoft). Crie restrições de endereço IP e faça a gestão de identidades de serviço.
Modelos de aplicação – escolha entre uma lista extensa de modelos de aplicação no Azure
Marketplace, como o WordPress, o Joomla e o Drupal.
Integração do Visual Studio – as ferramentas dedicadas do Visual Studio simplificam o trabalho de
criar, implementar e depurar.
Funcionalidades API e mobile - O App Service fornece suporte CORS chave-na-mão para cenários
restful API, e simplifica cenários de aplicações móveis permitindo a autenticação, sincronização de
dados offline, notificações push e muito mais.
Código sem ser vidor - Execute um fragmento de código ou script a pedido, sem ter de aprovisionar
ou gerir a infraestrutura explicitamente, e pague apenas o tempo de computação que o seu código
utiliza (veja Azure Functions (Funções do Azure)).
Além do Serviço de Aplicações, o Azure oferece outros serviços que podem ser utilizados para hospedar
websites e aplicações web. Para a maioria dos cenários, o App Service é a melhor escolha. Para uma
arquitetura de microsserviço, considere o Service Fabric. Se precisar de mais controlo sobre as VMs em
que o seu código é executado, considere as Máquinas Virtuais do Azure. Para obter mais informações
sobre como escolher entre estes serviços do Azure, consulte a Comparação entre o App Service do
Azure, as Virtual Machines, o Service Fabric e os Cloud Services.
Passos seguintes
Crie a sua primeira aplicação Web.
ASP.NET Core
ASP.NET
PHP
Ruby (no Linux)
Node.js
Java
Python (no Linux)
HTML
Introdução ao Serviço de Aplicações do Azure no
Linux
O Azure App Service é uma plataforma computacional totalmente gerida que está otimizada para hospedar
websites e aplicações web. Os clientes podem utilizar o Serviço de Aplicações no Linux para alojar aplicações
Web nativamente no Linux para pilhas de aplicações suportadas.
Linguagens
O Serviço de Aplicações no Linux suporta um número de imagens Incorporadas para aumentar a produtividade
do programador. As línguas incluem: Node.js, Java (JRE 8 & JRE 11), PHP, Python, .NET Core e Ruby. Corra
az webapp list-runtimes --linux para ver as últimas línguas e versões suportadas. Se o runtime pedido pela sua
aplicação não for suportado nas imagens incorporadas, existem instruções sobre como criar a sua própria
imagem do Docker para implementar a Aplicação Web para Contentores.
Implementações
FTP
Git Local
GitHub
Bitbucket
DevOps
Ambientes de teste
Azure Container Registry e DockerHub CI/CD
Consola, Publicação e Depuração

Ambientes
Implementações
Consola básica
SSH
Dimensionamento
Os clientes podem aumentar ou reduzir aplicações Web ao alterar o escalão do respetivo plano do Serviço de
Aplicações
Localizações
Verifique o Dashboard de Estado do Azure.
Limitações
O portal do Azure mostra apenas as funcionalidades que funcionam atualmente para a Aplicação Web para
Contentores. À medida que ativamos mais funcionalidades, estas tornam-se visíveis no portal.
O Serviço de Aplicações no Linux só é suportado com planos de serviço de aplicação Gratuito, Básico, Standard e
Premium e não tem um nível Partilhado. Não é possível criar uma Aplicação Web Linux num plano de Serviço de
Aplicações que já acolhe aplicações web não linux.
Com base numa limitação atual, para o mesmo grupo de recursos não é possível misturar aplicações Windows e
Linux na mesma região.
NOTE
Há uma nova capacidade integrada de exploração madeireira com a Monitorização Azure (pré-visualização) .
Quando a aplicação não consegue iniciar ou pretende verificar o registo da sua aplicação, verifique os registos do
Docker no diretório LogFiles. Pode aceder a este diretório através do seu site SCM ou do FTP. Para registar
stdout stderr o e a partir do seu recipiente, é necessário ativar o registo de registos de aplicações em
registos de serviços de aplicações . A regulação entra em vigor imediatamente. O Serviço de Aplicações deteta a
alteração e reinicia automaticamente o recipiente.
Pode aceder ao site do SCM através das Ferramentas Avançadas no menu Ferramentas de
Desenvolvimento .
Passos seguintes
Os artigos seguintes ajudam-no a começar a utilizar o Serviço de Aplicações no Linux com aplicações Web
escritas em várias linguagens:
.NET Core
PHP
Node.js
Java
Python
Ruby
Ir
Aplicação com vários contentores
Para mais informações sobre o Serviço de Aplicações no Linux, consulte:
FAQ do Serviço de Aplicações para Linux
Suporte SSH para o Serviço de Aplicações no Linux
Configurar ambientes de teste no Serviço de Aplicações
Implementação contínua do Hub do Docker
Pode publicar perguntas e problemas no nosso fórum.
Introdução aos Ambientes de Serviço de Aplicações
Descrição geral
O Ambiente de Serviço de Aplicações do Azure é uma funcionalidade do Serviço de Aplicações do Azure que
fornece um ambiente totalmente isolado e dedicado para executar com segurança as aplicações do Serviço de
Aplicações em grande escala. Esta capacidade pode alojar:
Aplicações Web do Windows
Aplicações Web do Linux
Contentores do Docker
Aplicações móveis
Funções
Os ambientes de Serviço de Aplicações (ASEs) são adequados para cargas de trabalho de aplicações que
exigem:
Dimensionamento muito elevado.
Isolamento e acesso a uma rede segura.
Utilização de memória elevada.
Os clientes podem criar vários ASEs numa única região do Azure ou em várias regiões do Azure. Esta
flexibilidade torna os ASEs ideais para dimensionar horizontalmente camadas de aplicações sem monitorização
de estado para suportar cargas de trabalho RPS elevadas.
AsEs acolhe aplicações de apenas um cliente e fazê-lo num dos seus VNets. Os clientes têm um controlo
otimizado sobre o tráfego de rede de aplicações de entrada e saída. As aplicações podem estabelecer ligações
seguras de alta velocidade em VPNs aos recursos da empresa no local.
O ASE vem com o seu próprio escalão de preço. Saiba como a Oferta isolada ajuda a orientar a segurança e
a hiperescala.
Os Ambientes do Serviço de Aplicações v2 fornecem um ambiente para proteger as aplicações numa sub-
rede da sua rede e fornece a sua própria implementação privada do Serviço de Aplicações do Azure.
É possível utilizar múltiplos ASEs para dimensionar horizontalmente. Para obter mais informações, veja
como configurar requisitos de espaço de uma aplicação geodistribuída.
Os ASEs podem ser utilizados para configurar a arquitetura de segurança, conforme apresentado no
AzureCon Deep Dive. Para ver como a arquitetura de segurança apresentada no AzureCon Deep Dive foi
configurada, veja o artigo sobre como implementar uma arquitetura de segurança por camadas com
ambientes de Serviço de Aplicações.
As aplicações em execução em ASEs podem ter o seu acesso protegido por dispositivos a montante, tais
como firewalls de aplicações Web (WAFs). Para obter mais informações, veja Firewall de aplicações Web
(WAF).
Os ambientes de serviço de aplicações podem ser implantados em Zonas de Disponibilidade (AZ) utilizando
a fixação de zona. Consulte o Suporte ambiental do serviço de aplicações para as zonas de disponibilidade
para obter mais detalhes.
Ambiente dedicado
Um ASE é dedicado exclusivamente a uma subscrição individual e pode alojar 100 instâncias do Plano do
Serviço de Aplicações. O intervalo pode abranger de 100 instâncias num único plano do Serviço de Aplicações
até 100 planos do Serviço de Aplicações de instância única, e tudo o que está dentro deste intervalo.
Um ASE é composto por front-ends e trabalhos. Os front-ends são responsáveis pela terminação de
HTTP/HTTPS e pelo balanceamento de carga automático de pedidos de aplicações num ASE. Os front-ends são
adicionados automaticamente à medida que os planos do Serviço de Aplicações no ASE são aumentados
horizontalmente.
Os trabalhos são funções que alojam aplicações de cliente. Os trabalhos estão disponíveis em três tamanhos
fixos:
Uma vCPU/3,5 GB de RAM
Duas vCPU/7 GB de RAM
Quatro vCPU/14 GB de RAM
Os clientes não precisam de gerir os front-ends e os trabalhos. Toda a infraestrutura é automaticamente
adicionada à medida que os clientes aumentam horizontalmente os respetivos planos do Serviço de Aplicações.
À medida que os planos do Serviço de Aplicações são criados ou reduzidos verticalmente num ASE, a
infraestrutura necessária é adicionada ou removida, conforme adequado.
Existe uma tarifa mensal fixa para um ASE que paga a infraestrutura e não muda com base no tamanho do ASE.
Além disso, existe um custo por vCPU do plano do Serviço de Aplicações. Todas as aplicações alojadas num ASE
estão na SKU de preços Isolada. Para obter informações sobre os preços de um ASE, veja a página Preços de
Serviço de Aplicações e consulte as opções disponíveis para ASEs.
Suporte de rede virtual

A funcionalidade ASE é uma implantação do Serviço de Aplicações Azure diretamente na rede virtual do Gestor
de Recursos Azure de um cliente. Para saber mais sobre as redes virtuais do Azure, veja as Perguntas
Frequentes sobre as redes virtuais do Azure. Um ASE existe sempre numa rede virtual e, mais precisamente,
numa sub-rede de uma rede virtual. Pode utilizar as funcionalidades de segurança das redes virtuais para
controlar as comunicações de rede de entrada e saída para as suas aplicações.
Um ASE pode ter acesso à Internet com um endereço IP público ou ter acesso interno apenas com um endereço
do balanceador de carga interno (ILB) do Azure.
Os Grupos de Segurança de Rede restringem as comunicações de rede de entrada para a sub-rede onde um
ASE se encontra. Pode utilizar NSGs para executar aplicações atrás de dispositivos e serviços a montante, tais
como WAFs e fornecedores de SaaS de rede.
As aplicações também precisam de aceder frequentemente a recursos da empresa, tais como bases de dados
internas e serviços Web. Se implementar o ASE numa rede virtual que tenha uma ligação VPN à rede no local,
as aplicações no ASE podem aceder aos recursos no local. Esta capacidade é verdadeira, independentemente de
a VPN ser uma rede de VPNs ou uma VPN Azure ExpressRoute.
Para obter mais informações sobre como os ASEs funcionam com redes virtuais e redes no local, veja
Considerações sobre a rede do Ambiente de Serviço de Aplicações.
Ambiente do Serviço de Aplicações v1

O Ambiente de Serviço de Aplicações tem duas versões: ASEv1 e ASEv2. As informações anteriores tiveram
como base a versão ASEv2. Esta secção mostra as diferenças entre as versões ASEv1 e ASEv2.
No ASEv1, é necessário gerir todos os recursos manualmente. Tal inclui os front-ends, os trabalhos e os
endereços IP utilizados para SSL baseado em IP. Para poder aumentar horizontalmente o seu plano do Serviço
de Aplicações, primeiro tem de aumentar horizontalmente o conjunto de processos de trabalho onde pretende
alojá-lo.
O ASEv1 utiliza um modelo de preços diferente do ASEv2. No ASEv1, paga por cada vCPU alocada. Tal inclui as
vCPUs utilizadas para front-ends ou trabalhos que não estejam a alojar quaisquer cargas de trabalho. No ASEv1,
o tamanho de dimensionamento máximo predefinido de um ASE é 55 anfitriões no total. Tal inclui os trabalhos
e os front-ends. Uma vantagem do ASEv1 é que pode ser implementado numa rede virtual clássica e numa rede
virtual do Resource Manager. Para saber mais sobre o ASEv1, veja o artigo Introdução ao Ambiente de Serviço
de Aplicações v1.
Quickstart: Criar uma aplicação web ASP.NET Core
em Azure
Neste arranque rápido, aprenderá a criar e implementar a sua primeira ASP.NET aplicação web Core para o Azure
App Service.
Quando terminar, terá um grupo de recursos Azure composto por um plano de hospedagem do Serviço de
Aplicações e um Serviço de Aplicações com uma aplicação web implementada.
Pré-requisitos
Uma conta Azure com uma subscrição ativa. Crie uma conta gratuitamente.
Este quickstart implementa uma aplicação para o Serviço de Aplicações no Windows. Para implementar um
Serviço de Aplicações no Linux, consulte Criar uma aplicação Web .NET Core no Serviço de Aplicações no
Linux.
Instale o Visual Studio 2019 com a carga de trabalho de ASP.NET e desenvolvimento web.
Se já instalou o Visual Studio 2019:
Instale as últimas atualizações no Estúdio Visual selecionando A Verificação de Ajuda > para
Atualizações .
Adicione a carga de trabalho selecionando ferramentas > obter ferramentas e funcionalidades .
Criar uma aplicação Web ASP.NET Core

Crie uma aplicação web ASP.NET Core no Estúdio Visual seguindo estes passos:
1. Open Visual Studio e selecione Criar um novo projeto.
2. Em Criar um novo projeto, selecione ASP.NET Core Web Application e confirme que C# está listado nos
idiomas para essa escolha e, em seguida, selecione Next .
3. Na Configuração do seu novo projeto, nomeie o seu projeto de aplicação web myFirstAzureWebApp, e
selecione Create .
4. Pode implementar qualquer tipo de ASP.NET aplicação web Core para o Azure, mas para este arranque
rápido, escolha o modelo de Aplicação Web. Certifique-se de que a Autenticação está definida para não
autenticação, e que nenhuma outra opção é selecionada. Em seguida, selecione Criar .
5. A partir do menu do Estúdio Visual, selecione Debug > Star t Without Debugging para executar a sua
aplicação web localmente.
Publique a sua aplicação web
Para publicar a sua aplicação web, primeiro tem de criar e configurar um novo Serviço de Aplicações para o que
pode publicar a sua aplicação.
Como parte da configuração do Serviço de Aplicações, irá criar:
Um novo grupo de recursos para conter todos os recursos do Azure para o serviço.
Um novo Plano de Hospedagem que especifica a localização, tamanho e funcionalidades da quinta do servidor
web que acolhe a sua aplicação.
Siga estes passos para criar o seu Serviço de Aplicações e publique a sua aplicação web:
1. No Solution Explorer, clique à direita no projeto myFirstAzureWebApp e selecione Publish . Se ainda
não se inscreveu na sua conta Azure do Visual Studio, selecione adicionar uma conta ou iniciar sessão .
Também pode criar uma conta Azure gratuita.
2. Na caixa de diálogo de alvo Pick , escolha o Ser viço de Aplicações, selecione Criar Novo e, em seguida,
selecione Criar Perfil .
3. No Serviço de Aplicações: Crie um novo diálogo, forneça um Nome globalmente único para a sua
aplicação, aceitando o nome predefinido ou inserindo um novo nome. Os caracteres a-z válidos são: , A-Z ,
0-9 e - . Este Nome é usado como prefixo URL para http://<app_name>.azurewebsites.net a sua aplicação
web no formato .
4. Para Subscrição , aceite a subscrição listada ou selecione uma nova da lista de drop-down.
5. No grupo Recursos, selecione New . Em novo nome de grupo de recursos, insira o myResourceGroup e
selecione OK .
6. Para plano de hospedagem, selecione New .
7. No Plano de Acolhimento: Criar um novo diálogo, introduza os valores especificados no quadro
seguinte:
DEF IN IÇ Ã O VA LO R SUGERIDO DESC RIÇ Ã O
Plano de Hospedagem myFirstAzureWebAppPlan Nome do plano de serviço de

aplicações.
Localização Europa ocidental O centro de dados onde o a

aplicação Web está alojada.
Tamanho Gratuito O escalão de preço determina as

funcionalidades do alojamento.
8. Deixe as informações de aplicação definidaspara nenhuma .
9. No Ser viço de Aplicações: Criar uma nova caixa de diálogo, selecione Criar para começar a criar os
recursos Azure.
10. Assim que o assistente estiver concluído, selecione Publicar .

O Visual Studio publica a sua ASP.NET aplicação web Core para o Azure, e lança a aplicação no seu
navegador padrão.
Parabéns! A sua aplicação web ASP.NET Core está a funcionar ao vivo no Azure App Service.
Atualizar a aplicação e reimplementar

Siga estes passos para atualizar e reimplementar a sua aplicação web:
1. No Solution Explorer, no âmbito do seu projeto, abra oÍndice de Páginas.cshtml Pages > .
2. Substitua <div> a etiqueta inteira pelo seguinte código:
<div class="jumbotron">
<h1>ASP.NET in Azure!</h1>
<p class="lead">This is a simple app that we've built that demonstrates how to deploy a .NET app to
Azure App Service.</p>
</div>
3. Para voltar a implementar no Azure, clique com o botão direito do rato no projeto myFirstAzureWebApp ,
no Explorador de Soluções e selecione Publicar .
4. Na página resumo da Publicação, selecione Publicar .
Quando a publicação estiver concluída, o Visual Studio inicia um browser para o URL da aplicação Web.
Gerir a app Azure

Para gerir a sua aplicação web, vá ao portal Azuree procure e selecione Serviços de Aplicações.
Na página de Serviços de Aplicações, selecione o nome da sua aplicação web.

A página 'Over view' da sua aplicação web contém opções para a gestão básica como navegar, parar, começar,
reiniciar e eliminar. O menu esquerdo fornece mais páginas para configurar a sua aplicação.
Limpar recursos
Nos passos anteriores, criou os recursos do Azure num grupo de recursos. Se provavelmente não necessitar
desses recursos no futuro, pode eliminá-los ao eliminar o grupo de recursos.
A partir do menu do portal Azure ou página inicial, selecione Grupos de Recursos, e na página dos grupos
de Recursos, selecione myResourceGroup .
Na página myResourceGroup, certifique-se de que os recursos listados são os que pretende eliminar.
Selecione Eliminar o grupo de recursos, digite o myResourceGroup na caixa de texto para confirmar e, em
seguida, selecione Eliminar .
Passos seguintes
Neste arranque rápido, usou o Visual Studio para criar e implementar uma aplicação web ASP.NET Core para o
Azure App Service.
Avançar para o próximo artigo para aprender a criar uma aplicação .NET Core e conectá-la a uma Base de Dados
SQL:
ASP.NET Core com a Base de Dados SQL
Criar uma aplicação Web ASP.NET Framework no
Azure
O Serviço de Aplicações do Azure oferece um serviço de alojamento na Web altamente dimensionável e com
correção automática.
Este quickstart mostra como implementar a sua primeira aplicação web ASP.NET para o Azure App Service.
Quando terminar, terá um plano de Serviço de Aplicações. Você também terá uma app de Serviço de Aplicações
com uma aplicação web implementada.
Se não tiver uma subscrição do Azure,crie uma conta gratuita antes de começar.
Pré-requisitos
Para completar este tutorial, instale o Visual Studio 2019 com a ASP.NET e a carga de trabalho de
desenvolvimento web.
Se já instalou o Visual Studio 2019:
Atualizações .
Adicione a carga de trabalho selecionando ferramentas > obter ferramentas e funcionalidades .
Criar uma aplicação web ASP.NET

Crie uma aplicação web ASP.NET seguindo estes passos:
1. Abra o Estúdio Visual e, em seguida, selecione Criar um novo projeto .
2. Em Criar um novo projeto, encontre e escolha ASP.NET Aplicação Web (.QUADRO NET) e, em
seguida, selecione Next .
3. No Configure o seu novo projeto, nomeie a aplicação myFirstAzureWebApp, e depois selecione
Create .
4. Pode implementar qualquer tipo de aplicação Web ASP.NET no Azure. Para este arranque rápido, escolha o
modelo MVC.
5. Certifique-se de que a autenticação está definida para não autenticação. Selecione Criar .
6. A partir do menu do Estúdio Visual, selecione Debug > Star t Without Debugging para executar a
Publique a sua aplicação web
1. No Solution Explorer, clique à direita no projeto myFirstAzureWebApp e selecione Publish .
2. Escolha o Ser viço de Aplicações e selecione Criar o perfil .
3. No Ser viço de Aplicações Criar novas , as suas opções dependem se já está inscrito no Azure e se tem
uma conta visual studio ligada a uma conta Azure. Selecione Adicionar uma conta ou iniciar sessão
para iniciar sessão na subscrição do Azure. Se já assinou, selecione a conta que deseja.
NOTE
Se já tiver sessão iniciada, não selecione ainda Criar .
Um grupo de recursos é um contentor lógico em que os recursos do Azure, como aplicações Web, bases
de dados e contas de armazenamento são implementados e geridos. Por exemplo, pode optar por eliminar
todo o grupo de recursos num único passo simples mais tarde.
4. Para o grupo Recursos, selecione New .
5. Em novo nome de grupo de recursos, insira o myResourceGroup e selecione OK .
Um plano do serviço de aplicações especifica o local, tamanho e funcionalidades da farm de servidores
Web que aloja a aplicação. Pode economizar dinheiro ao alojar várias aplicações, configurando as
aplicações Web para partilhar um único plano do serviço de aplicações.
Os planos do Serviço de Aplicações definem:
Região (por exemplo: Europa do Norte, E.U.A. Leste, Ásia Sudeste)
Tamanho da instância (pequena, média, grande)
Contagem do dimensionamento (1 a 20 instâncias)
SKU (Gratuito, Partilhado, Básico, Standard ou Premium)
6. Para o Plano de Hospedagem, selecione New .
7. No diálogo do Plano de Hospedagem Configurar, introduza os valores a partir da tabela seguinte e, em
seguida, selecione OK .

Plano de Alojamento myAppServicePlan Nome do plano de serviço de

aplicações.
Localização Europa ocidental O centro de dados onde o a

aplicação Web está alojada.
Tamanho Gratuito O escalão de preço determina as

funcionalidades do alojamento.
8. Em Nome, introduza um nome de aplicação A-Z 0-9 único - que inclua apenas os caracteres válidos,
a-z e . Pode aceitar o nome único gerado automaticamente. O URL da aplicação Web é
http://<app-name>.azurewebsites.net , em que <app-name> é o nome da aplicação.
9. Selecione Criar para começar a criar os recursos do Azure.

Assim que o assistente estiver concluído, os recursos Azure são criados para si e está pronto para publicar.
10. Na página Publicar, clique em Publicar . O Visual Studio constrói, embala e publica a app para o Azure, e
depois lança a app no navegador padrão.
O nome da aplicação especificado no Ser viço de Aplicações Criar nova página é usado como prefixo URL no
formato http://<app-name>.azurewebsites.net .
Parabéns! A sua ASP.NET aplicação web está a funcionar ao vivo no Azure App Service.
Atualizar a aplicação e reimplementar

1. No Solution Explorer, no âmbito do seu projeto, abra views > home > index.cshtml .
2. Localize a etiqueta HTML <div class="jumbotron"> na parte superior e substitua todo o elemento pelo
código seguinte:
<p class="lead">This is a simple app that we've built that demonstrates how to deploy a .NET app
to Azure App Service.</p>
</div>
3. Para voltar a implementar no Azure, clique com o botão direito do rato no projeto
myFirstAzureWebApp , no Explorador de Soluções e selecione Publicar . Em seguida, selecione
Publicar .
Quando a publicação estiver concluída, o Visual Studio inicia um browser para o URL da aplicação Web.
Gerir a app Azure

1. Para gerir a aplicação web, vá ao portal Azuree procure e selecione Serviços de Aplicações.
2. Na página de Serviços de Aplicações, selecione o nome da sua aplicação web.
É apresentada a página de descrição geral da sua aplicação Web. Aqui, pode fazer gestão básica como
navegar, parar, começar, reiniciar e apagar.
O menu à esquerda fornece diferentes páginas para configurar a sua aplicação.
Limpar recursos
A partir do menu do portal Azure ou página inicial, selecione Grupos de Recursos, e na página dos grupos
de Recursos, selecione myResourceGroup .
Na página myResourceGroup, certifique-se de que os recursos listados são os que pretende eliminar.
Selecione Eliminar o grupo de recursos, digite o myResourceGroup na caixa de texto para confirmar e, em
seguida, selecione Eliminar .
Passos seguintes
ASP.NET com Base de Dados SQL
Criar uma aplicação Web Node.js no Azure
Começa com o Azure App Service criando uma aplicação Node.js/Express localmente usando o Código do Estúdio
Visual e, em seguida, implementando a app para a nuvem. Como utiliza um nível de Serviço de Aplicações
gratuito, não tem custos para completar este arranque rápido.
Pré-requisitos
Uma conta Azure com uma subscrição ativa. Crie uma conta gratuita.
Nó.js e npm. Verifique o comando node --version para verificar se o Node.js está instalado.
Visual Studio Code.
A extensão do Serviço de Aplicações Azure para Código de Estúdio Visual.
Clone e executar uma aplicação local de Node.js

1. No seu computador local, abra um terminal e clone o repositório de amostras:
git clone https://github.com/Azure-Samples/nodejs-docs-hello-world
2. Navegue na nova pasta de aplicações:
cd nodejs-docs-hello-world
3. Inicie a aplicação para testá-la localmente:
npm start
4. Abra o seu navegador e navegue para http://localhost:1337 . O navegador deve exibir "Hello World!".
5. Pressione ctrl + C no terminal para parar o servidor.
Dei conta de um problema.
Implementar a aplicação no Azure

Nesta secção, implementa a sua aplicação Node.js para a Azure utilizando o Código VS e a extensão do Serviço de
Aplicações Azure.
1. No terminal, certifique-se de que está na pasta nodejs-docs-hello-world e, em seguida, inicie o Código do
Estúdio Visual com o seguinte comando:
code .
2. Na barra de atividade do Código VS, selecione o logótipo Azure para mostrar o explorador do Ser viço
app AZURE. Selecione Iniciar súm em Azure... e siga as instruções. (Ver resolução de problemas Azure
abaixo se encontrar erros.) Uma vez assinado, o explorador deve mostrar o nome da sua subscrição Azure.
3. No explorador de SERVIÇO DE APLICAÇÃO AZURE do Código VS, selecione o ícone de seta azul para
cima para implementar a sua aplicação para o Azure. (Também pode invocar o mesmo comando a partir da
Paleta de Comando (Ctrl + Shift + P) digitando 'implementar para a web app' e escolhendo o Serviço de
Aplicações Azure: Implementar para a Web App).
4. Escolha a pasta nodejs-docs-hello-world.

5. Escolha uma opção de criação baseada no sistema operativo para o qual pretende implementar:
Linux: Escolha Criar nova Aplicação Web
Windows: Escolha Criar nova Aplicação Web... Avançado
6. Digite um nome globalmente único para a sua aplicação web e prima Enter . O nome deve ser único em
toda a Azure e usar apenas caracteres alfanuméricos ('A-Z', 'a-z', e '0-9') e hífenes ('-').
7. Se for direcionado para o Linux, selecione uma versão Node.js quando solicitado. Recomenda-se uma
versão LTS.
8. Se direcionar o Windows, siga as indicações adicionais:
a. Selecione Criar um novo grupo de recursos e, em seguida, insira um nome para o grupo de
recursos, como AppServiceQS-rg .
b. Selecione Windows para o sistema operativo.
c. Selecione Crie um novo plano de Ser viço de Aplicações e, em seguida, insira um nome para o
plano (como), AppServiceQS-plan em seguida, selecione F1 Grátis para o nível de preços.
d. Escolha Skip por agora quando solicitado sobre Insights de Aplicação.
e. Escolha uma região perto de si ou perto de recursos a que deseje aceder.
9. Depois de responder a todas as solicitações, o CÓDIGO VS mostra os recursos Azure que estão a ser criados
para a sua aplicação no pop-up de notificação.
Ao implementar para o Linux, selecione Sim quando solicitado para atualizar a sua configuração para
executar npm install no servidor Linux alvo.
10. Selecione Sim quando solicitado com Sempre implemente o espaço de trabalho "nodejs-docs-
hello-world" para (nome da aplicação)" . Selecionar Sim diz ao Código VS para direcionar
automaticamente a mesma App Service Web App com implementações subsequentes.
11. Se implementar para o Linux, selecione Browse Website na solicitação para ver a sua aplicação web
recentemente implantada uma vez concluída a implementação. O navegador deve exibir "Hello World!"
12. Se implementar para o Windows, deve primeiro definir o número da versão Node.js para a aplicação web:
a. No Código VS, expanda o nó para o novo serviço de aplicações, clique com o botão direito
Definições de aplicação e selecione Adicionar Nova Definição...
b. Introduza WEBSITE_NODE_DEFAULT_VERSION para a tecla de definição.

c. Introduza 10.15.2 o valor de definição.
d. Clique no nó para o serviço de aplicações e selecione Restar t
e. Clique no nó para o serviço de aplicações mais uma vez e selecione Browse Website .
Resolução de problemas Azure sign-in
Se vir o erro "Não é possível encontrar subscrição com nome [ID de subscrição]" ao iniciar sessão no
Azure, pode ser porque está por detrás de um representante e não consegue chegar à API Azure. Configure
HTTP_PROXY HTTPS_PROXY variáveis e ambientais com a sua informação de procuração no seu terminal utilizando
export .
export HTTPS_PROXY=https://username:password@proxy:8080
export HTTP_PROXY=http://username:password@proxy:8080
Se a definição das variáveis ambientais não corrigir o problema, contacte-nos selecionando o I deparar-se com
um botão de problema acima.
Atualizar a aplicação
Pode implementar alterações nesta aplicação, fazendo edições no Código VS, guardando os seus ficheiros e, em
seguida, usando o mesmo processo que antes apenas de escolher a app existente em vez de criar uma nova.
Visualização de registos
Pode visualizar a saída de registo (chamadas console.log para) a partir da aplicação diretamente na janela de
saída do Código VS.
1. No explorador do Ser viço de APLICAÇÕES AZURE, clique com o nó da aplicação e escolha Iniciar
Registos de Streaming.
2. Quando solicitado, opte por ativar a registo e reiniciar a aplicação. Uma vez reiniciada a aplicação, a janela
de saída do Código VS abre-se com uma ligação ao fluxo de registo.
3. Após alguns segundos, a janela de saída mostra uma mensagem indicando que está ligado ao serviço de
streaming de registos. Pode gerar mais atividade de saída refrescando a página no navegador.
Connecting to log stream...

2020-03-04T19:29:44 Welcome, you are now connected to log-streaming service. The default
timeout is 2 hours.
Change the timeout with the App Setting SCM_LOGSTREAM_TIMEOUT (in seconds).
Passos seguintes
Parabéns, conseguiste completar esta rapidinha!
Em seguida, confira as outras extensões do Azure.
BD do Cosmos
Funções do Azure
Ferramentas do Docker
Ferramentas Azure CLI
Ferramentas de gestor de recursos Azure
Ou obtenha-os todos instalando o pacote de extensões Node para Azure.
Criar uma aplicação Web PHP no Azure
NOTE
Este artigo implementa uma aplicação no Serviço de Aplicações no Windows. Para implementar um Serviço de Aplicações no
Linux, consulte Criar uma aplicação Web PHP no Serviço de Aplicações no Linux.
correção automática. Este tutorial de arranque rápido mostra como implementar uma aplicação PHP para o Azure
App Service. Crie a aplicação Web com a CLI do Azure no Cloud Shell e utilize o Git para implementar o código
PHP de exemplo para a aplicação Web.
Pode seguir os passos aqui indicados num computador Mac, Windows ou Linux. Depois de instalados os pré-
requisitos, demora cerca de cinco minutos a concluir todos os passos.
Pré-requisitos
Para concluir este guia de início rápido:
Instalar o Git
Instalar PHP
Transferir o exemplo localmente

Numa janela de terminal, execute os comandos seguintes. Desta forma, o exemplo de aplicação é clonado no seu
computador local e é encaminhado para o diretório que contém o código de exemplo.
git clone https://github.com/Azure-Samples/php-docs-hello-world

cd php-docs-hello-world
Executar a aplicação localmente

Execute a aplicação localmente, para ver que aspeto deveria ter quando a implemente no Azure. Abra uma janela
do terminal e use o comando php para iniciar o servidor Web PHP incorporado.
php -S localhost:8080
Abra um browser e navegue para a aplicação de exemplo em http://localhost:8080 .
Pode ver a mensagem Olá, mundo! da aplicação de exemplo apresentada na página.
Na janela do terminal, prima Ctrl+C para sair do servidor Web.
Utilizar o Azure Cloud Shell

O Azure aloja o Azure Cloud Shell, um ambiente de shell interativo que pode utilizar através do seu browser. Pode
utilizar o Bash ou o PowerShell com o Cloud Shell para trabalhar com os serviços do Azure. Pode utilizar os
comandos pré-instalados do Cloud Shell para executar o código neste artigo sem ter de instalar nada no ambiente
local.
Para iniciar o Azure Cloud Shell:
OPÇ ÃO EXEM P LO / L IGA Ç Ã O
Selecione Experimentar no canto superior direito de um

bloco de código. A seleção de Experimente não copia
automaticamente o código para o Cloud Shell.
Aceda a https://shell.azure.com ou selecione o botão Iniciar

Cloud Shell para abrir o Cloud Shell no browser.
Selecione o botão Cloud Shell na barra de menus, na parte

direita do portal do Azure.
Para executar o código neste artigo no Azure Cloud Shell:

1. Inicie o Cloud Shell.
2. Selecione o botão Copiar num bloco de código para copiar o código.
3. Cole o código na sessão do Cloud Shell ao selecionar Ctrl +Shift +V no Windows e Linux ou Cmd +Shift +V
no macOS.
4. Selecione Introduzir para executar o código.
Configurar um utilizador de implementação

FtP e Git local podem implantar-se numa aplicação web Azure utilizando um utilizador de implementação. Assim
que configurar o utilizador de implementação, pode utilizá-lo para todas as suas implementações Azure. O seu
nome de utilizador de implementação de nível de conta e palavra-passe são diferentes das credenciais de
subscrição do Azure.
Para configurar o utilizador de implementação, execute o comando de conjunto de utilizadores de implementação
de webapp az em Azure Cloud Shell. Substitua <o <nome de utilizador> e a palavra-passe> por um nome de
utilizador e palavra-passe de implementação.
O nome de utilizador deve ser único dentro do Azure e, para os pushs git locais, não deve conter o símbolo '@'.
A palavra-passe deve ter pelo menos oito caracteres de comprimento, com dois dos seguintes três elementos:
letras, números e símbolos.
az webapp deployment user set --user-name <username> --password <password>
A saída JSON mostra null a palavra-passe como . Se obtiver o erro 'Conflict'. Details: 409 , altere o nome de
utilizador. Se obtiver o 'Bad Request'. Details: 400 erro, utilize uma palavra-passe mais forte.
Grave o seu nome de utilizador e palavra-passe para utilizar para implementar as suas aplicações web.
Criar um grupo de recursos

Um grupo de recursos é um contentor lógico em que os recursos do Azure, como aplicações Web, bases de dados
e contas de armazenamento são implementados e geridos. Por exemplo, pode optar por eliminar todo o grupo de
recursos num único passo simples mais tarde.
Na Cloud Shell, crie um az group create grupo de recursos com o comando. O exemplo seguinte cria um grupo
de recursos com o nome myResourceGroup, na localização Europa Ocidental. Para ver todas as localizações
suportadas para o Serviço de Aplicações no escalão Gratuito , execute o comando
az appservice list-locations --sku FREE .
az group create --name myResourceGroup --location "West Europe"
Geralmente, o grupo de recursos e os recursos são criados numa região perto de si.
Quando o comando for concluído, uma saída JSON mostra as propriedades do grupo de recursos.
Criar um plano do Serviço de Aplicações do Azure

Na Cloud Shell, crie um az appservice plan create plano de Serviço de Aplicações com o comando.
O exemplo seguinte cria um plano do Serviço de Aplicações com o nome myAppServicePlan , que utiliza o escalão
de preços Gratuito .
az appservice plan create --name myAppServicePlan --resource-group myResourceGroup --sku FREE
Quando o plano do Serviço de Aplicações tiver sido criado, a CLI do Azure mostra informações semelhantes ao
seguinte exemplo:
{
"adminSiteName": null,
"appServicePlanName": "myAppServicePlan",
"geoRegion": "West Europe",
"hostingEnvironmentProfile": null,
"id": "/subscriptions/0000-
0000/resourceGroups/myResourceGroup/providers/Microsoft.Web/serverfarms/myAppServicePlan",
"kind": "app",
"location": "West Europe",
"maximumNumberOfWorkers": 1,
"name": "myAppServicePlan",
< JSON data removed for brevity. >
"targetWorkerSizeId": 0,
"type": "Microsoft.Web/serverfarms",
"workerTierName": null
}
Criar uma aplicação Web

No Cloud Shell, crie uma aplicação Web no plano do Serviço de Aplicações myAppServicePlan com o comando
az webapp create .
No exemplo a seguir, substitua <app-name> com um nome de aplicação globalmente exclusivo (os carateres válidos
são a-z , 0-9 e - ). O runtime está definido como PHP|7.0 . Para ver todos os tempos de corrida suportados,
az webapp list-runtimes corra.
# Bash
az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name <app-name> --runtime
"PHP|7.4" --deployment-local-git
# PowerShell
az --% webapp create --resource-group myResourceGroup --plan myAppServicePlan --name <app-name> --runtime
NOTE
O símbolo de stop-parsing, (--%) introduzido no PowerShell 3.0, direciona a PowerShell a abster-se de interpretar a
entrada como comandos ou expressões PowerShell.
Quando a aplicação Web tiver sido criada, a CLI do Azure mostra informações semelhantes ao seguinte exemplo:
Local git is configured with url of 'https://<username>@<app-name>.scm.azurewebsites.net/<app-

name>.git'
{
"availabilityState": "Normal",
"clientAffinityEnabled": true,
"clientCertEnabled": false,
"cloningInfo": null,
"containerSize": 0,
"dailyMemoryTimeQuota": 0,
"defaultHostName": "<app-name>.azurewebsites.net",
"enabled": true,
}
Criou uma nova aplicação vazia, com a implementação de git habilitada.

NOTE
O URL do Git remoto é apresentado na propriedade deploymentLocalGitUrl , com o formato
https://<username>@<app-name>.scm.azurewebsites.net/<app-name>.git . Guarde este URL, uma vez que vai precisar
dele mais tarde.
Navegue para a sua aplicação Web recentemente criada. Substitua _ < o nome da aplicação>_ pelo nome único da
aplicação criado no passo anterior.
http://<app name>.azurewebsites.net
A aplicação Web deve ter o seguinte aspeto:
Enviar para o Azure a partir do Git

Regresse à janela de terminal local e adicione um remoto do Azure ao seu repositório Git local. Substitua * <a
implementaçãoLocalGitUrl-from-create-step>* com o URL do comando Git que guardou de Criar uma aplicação
web.
git remote add azure <deploymentLocalGitUrl-from-create-step>
Envie para o remoto do Azure para implementar a sua aplicação com o comando seguinte. Quando o Git
Credential Manager lhe pedir credenciais, certifique-se de introduzir as credenciais que criou na Configuração de
um utilizadorde implementação , e não as credenciais que utiliza para iniciar sessão no portal Azure.
git push azure master
Este comando pode demorar alguns minutos a ser executado. Ao executar, apresenta informações semelhantes ao
exemplo seguinte:
Counting objects: 2, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 352 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: Updating branch 'master'.
remote: Updating submodules.
remote: Preparing deployment for commit id '25f18051e9'.
remote: Generating deployment script.
remote: Running deployment command...
remote: Handling Basic Web Site deployment.
remote: Kudu sync from: '/home/site/repository' to: '/home/site/wwwroot'
remote: Copying file: '.gitignore'
remote: Copying file: 'LICENSE'
remote: Copying file: 'README.md'
remote: Copying file: 'index.php'
remote: Ignoring: .git
remote: Finished successfully.
remote: Running post deployment command(s)...
remote: Deployment successful.
To https://<app-name>.scm.azurewebsites.net/<app-name>.git
cc39b1e..25f1805 master -> master
Navegar para a aplicação

Utilize o browser para navegar para a aplicação implementada.
http://<app-name>.azurewebsites.net
O código PHP de exemplo está em execução numa aplicação Web do serviço de aplicações do Azure.
Parabéns! Implementou a sua primeira aplicação PHP no Serviço de Aplicações.
Atualizar localmente e reimplementar o código

Utilizando um editor de texto local, abra o ficheiro index.php na aplicação PHP e faça uma pequena alteração ao
texto na cadeia junto a echo :
echo "Hello Azure!";
Na janela terminal local, consolide as suas alterações no Git e envie as alterações ao código para o Azure.
git commit -am "updated output"

Depois de concluída a implementação, volte para a janela do browser aberta durante o passo Navegar para a
aplicação e atualize a página.
Gerencie a sua nova app Azure

1. Aceda ao portal do Azure para gerir a aplicação Web que criou. Procure e selecione Serviços de Aplicações .
2. Selecione o nome da sua aplicação Azure.
Será exibida a página de visão geral da sua aplicação web. Aqui, pode executar tarefas básicas de gestão
como Navegar, Parar, Reiniciar e Excluir.
O menu de aplicações web fornece diferentes opções para configurar a sua aplicação.
Limpar recursos
Nos passos anteriores, criou os recursos do Azure num grupo de recursos. Se achar que não vai precisar destes
recursos no futuro, execute o seguinte comando no Cloud Shell para eliminar o grupo de recursos:
az group delete --name myResourceGroup
Este comando pode demorar alguns minutos a ser executado.
Passos seguintes
PHP com MySQL
Quickstart: Criar uma aplicação Java no Azure App
Service no Windows
NOTE
Este artigo implementa uma aplicação no Serviço de Aplicações no Windows. Para implementar no Serviço de Aplicações em
Linux, consulte a aplicação Web Create Java no Linux.
correção automática. Este quickstart mostra como usar o CLI Azure com o Azure Web App Plugin para Maven
implementar um ficheiro java web archive (WAR).
NOTE
O mesmo também pode ser feito usando IDEs populares como IntelliJ e Eclipse. Consulte os nossos documentos
semelhantes no Azure Toolkit para IntelliJ Quickstart ou Azure Toolkit para Eclipse Quickstart.

local.




no macOS.
Criar uma aplicação em Java

Execute o seguinte comando Maven no pedido da Cloud Shell para criar uma nova aplicação chamada helloworld
:
mvn archetype:generate -DgroupId=example.demo -DartifactId=helloworld -DarchetypeArtifactId=maven-archetype-

webapp -Dversion=1.0-SNAPSHOT
Em seguida, mude o seu diretório de trabalho para a pasta do projeto:
cd helloworld
Configurar o plug-in do Maven

Pode executar o seguinte comando maven no Comando De comando Para configurar a implementação, escolher
'2' para o sistema operativo do windows no primeiro passo e, em seguida, aceitar as configurações predefinidas
pressionando ENTER até obter o pedido de Confirmação (Y/N) e, em seguida, prima 'y' e a configuração é feita.
mvn com.microsoft.azure:azure-webapp-maven-plugin:1.9.1:config
Um processo de amostra parece:
~@Azure:~/helloworld$ mvn com.microsoft.azure:azure-webapp-maven-plugin:1.9.1:config

[INFO] Scanning for projects...
[INFO]
[INFO] ----------------------< example.demo:helloworld >-----------------------
[INFO] Building helloworld Maven Webapp 1.0-SNAPSHOT
[INFO] --------------------------------[ war ]---------------------------------
[INFO]
[INFO] --- azure-webapp-maven-plugin:1.9.1:config (default-cli) @ helloworld ---
[WARNING] The plugin may not work if you change the os of an existing webapp.
Define value for OS(Default: Linux):
1. linux [*]
2. windows
3. docker
Enter index to use: 2
Define value for javaVersion(Default: 1.8):
1. 1.7
2. 1.7.0_191_ZULU
3. 1.7.0_51
4. 1.7.0_71
5. 1.7.0_80
6. 1.8 [*]
7. 1.8.0_102
8. 1.8.0_111
9. 1.8.0_144
10. 1.8.0_172
11. 1.8.0_172_ZULU
12. 1.8.0_181
13. 1.8.0_181_ZULU
14. 1.8.0_202
15. 1.8.0_202_ZULU
16. 1.8.0_25
17. 1.8.0_60
18. 1.8.0_73
19. 1.8.0_92
20. 11
21. 11.0.2_ZULU
Enter index to use:
Define value for webContainer(Default: tomcat 8.5):
1. jetty 9.1
2. jetty 9.1.0.20131115
3. jetty 9.3
4. jetty 9.3.13.20161014
5. tomcat 7.0
6. tomcat 7.0.50
7. tomcat 7.0.62
8. tomcat 8.0
9. tomcat 8.0.23
10. tomcat 8.5 [*]
11. tomcat 8.5.20
12. tomcat 8.5.31
13. tomcat 8.5.34
14. tomcat 8.5.37
15. tomcat 8.5.6
16. tomcat 9.0
17. tomcat 9.0.0
18. tomcat 9.0.12
19. tomcat 9.0.14
20. tomcat 9.0.8
Enter index to use:
Please confirm webapp properties
AppName : helloworld-1590394316693
ResourceGroup : helloworld-1590394316693-rg
Region : westeurope
PricingTier : PremiumV2_P1v2
OS : Windows
Java : 1.8
WebContainer : tomcat 8.5
Deploy to slot : false
Confirm (Y/N)? :
[INFO] Saving configuration to pom.
NOTE
Neste artigo, estamos a trabalhar apenas com aplicações Java em pacotes de ficheiros WAR. O plug-in também suporta
aplicações Web JAR, visite Implementar um ficheiro JAR do Java SE no Serviço de Aplicações no Linux para experimentar.
Aberto pom.xml para ver a configuração atualizada.
code pom.xml
Pode modificar as configurações do Serviço de Aplicações diretamente no seu ficheiro pom, se necessário,
algumas comuns estão listadas abaixo:
P RO P RIEDA DE N EC ESSÁ RIO DESC RIÇ Ã O VERSÃ O
<schemaVersion> false Especifique a versão do 1.5.2

esquema de configuração.
Os valores suportados são:
v1 v2 . .
<resourceGroup> true Grupo de Recursos Azure 0.1.0+

para a sua Aplicação Web.
<appName> true O nome da sua Aplicação 0.1.0+

Web.
<region> true Especifica a região onde a 0.1.0+

sua Web App será
hospedada; o valor
predefinido é westeurope .
Todas as regiões válidas na
secção Regiões Apoiadas.
<pricingTier> false O nível de preços da sua 0.1.0+

Web App. O valor
predefinido é P1V2 .
<runtime> true A configuração do ambiente 0.1.0+

de tempo de execução, pode
ver o detalhe aqui.
<deployment> true A configuração de 0.1.0+

implementação, pode ver os
detalhes aqui.
O processo de implantação para o Azure App Service utiliza credenciais de conta do Azure CLI. Inscreva-se com o
CLI Azure antes de continuar.
az login
Em seguida, pode implementar a sua aplicação Java para Azure utilizando o seguinte comando:
mvn package azure-webapp:deploy
Uma vez concluída a implementação, navegue para a aplicação implementada com o seguinte URL no seu browser,
por exemplo http://<webapp>.azurewebsites.net/ .
Parabéns! Implementou a sua primeira aplicação Java para o Serviço de Aplicações no Windows.
Limpar recursos
Passos seguintes
Ligue à base de dados Azure SQL com a Java
Ligue-se ao Azure DB para o MySQL com o Java
Ligue-se ao Azure DB para PostgreSQL com Java
Azure para Java Developers Resources
Saiba mais sobre os plugins maven para Azure
Criar uma aplicação Web HTML estática no Azure
correção automática. Este quickstart mostra como implementar um site básico HTML+CSS para o Serviço de
Aplicações Azure. Você completará este quickstart em Cloud Shell,mas também pode executar estes comandos
localmente com Azure CLI.

local.




3. Cole o código na sessão do Cloud Shell ao selecionar Ctrl +Shift +V no Windows e Linux ou
Cmd +Shift +V no macOS.
Transferir o exemplo
No Cloud Shell, crie um diretório de início rápido e, em seguida, altere-o.
mkdir quickstart
cd $HOME/quickstart
Em seguida, execute o seguinte comando para clonar o repositório da aplicação de exemplo para o seu diretório
de início rápido.
git clone https://github.com/Azure-Samples/html-docs-hello-world.git

Mude para o diretório que contém o código de exemplo e execute o comando az webapp up . No comando a
seguir, substitua <nome_aplicação> por um nome de aplicação exclusivo. O conteúdo estático --html é indicado
pela bandeira.
cd html-docs-hello-world
az webapp up --location westeurope --name <app_name> --html
O comando az webapp up executa as seguintes ações:

Cria um grupo de recursos predefinido.
Cria um plano do serviço de aplicações predefinido.
Cria uma aplicação com o nome especificado.
Implementa os ficheiros zip do diretório atual de trabalho para a aplicação Web.
exemplo seguinte:
{
"app_url": "https://<app_name>.azurewebsites.net",
"location": "westeurope",
"name": "<app_name>",
"os": "Windows",
"resourcegroup": "appsvc_rg_Windows_westeurope",
"serverfarm": "appsvc_asp_Windows_westeurope",
"sku": "FREE",
"src_path": "/home/<username>/quickstart/html-docs-hello-world ",
}
Anote o valor resourceGroup . Vai precisar dele na secção limpar recursos.
Navegar para a aplicação

Num browser, vá ao URL http://<app_name>.azurewebsites.net da aplicação: .
A página está a ser executada como uma aplicação Web do Serviço de Aplicações do Azure.
Parabéns! Implementou a sua primeira aplicação HTML no Serviço de Aplicações.
Atualizar e reimplementar a aplicação

No Cloud Shell, escreva nano index.html para abrir o editor de texto nano. No cabeçalho da etiqueta <h1> , altere
o "Serviço de Aplicações do Azure – Site HTML Estático de Exemplo" para -"Serviço de Aplicações do Azure",
conforme mostrado abaixo.
Guarde as alterações e feche o nano. Utilize o comando ^O para guardar e ^X para sair.
Agora irá implementar novamente a aplicação com o mesmo comando az webapp up .
az webapp up --location westeurope --name <app_name> --html
Depois de concluída a implementação, volte para a janela do browser aberta que abriu no passo Navegar para a
aplicação e atualize a página.
Gerencie a sua nova app Azure

Para gerir a aplicação web que criou, no portal Azure,procure e selecione Serviços de Aplicações.
Na página de Serviços de Aplicações, selecione o nome da sua aplicação Azure.

É apresentada a página de descrição geral da sua aplicação Web. Aqui, pode realizar tarefas de gestão básicas,
como navegar, parar, iniciar, reiniciar e eliminar.
O menu à esquerda fornece diferentes páginas para configurar a sua aplicação.
Limpar recursos
recursos no futuro, execute o seguinte comando no Cloud Shell para eliminar o grupo de recursos. Lembre-se de
que o nome do grupo de recursos foi gerado automaticamente para si no passo criar uma aplicação Web.
az group delete --name appsvc_rg_Windows_westeurope

Passos seguintes
Executar um contentor do Windows personalizado
no Azure (Pré-visualização)
O Serviço de Aplicações do Azure disponibiliza pilhas de aplicações predefinidas no Windows, como ASP.NET ou
Node.js, em execução no IIS. O ambiente do Windows reconfigurado bloqueia o sistema operativo a partir de
acesso administrativo, instalações de software, alterações na cache de montagem global, e assim por diante. Para
mais informações, consulte a funcionalidade do sistema operativo no Serviço de Aplicações Azure. Se a sua
aplicação precisar de mais acesso do que aquele que o ambiente pré-configurado permite, pode implementar um
contentor do Windows personalizado.
Este quickstart mostra como implementar uma aplicação ASP.NET, numa imagem do Windows, para Docker Hub
do Visual Studio. Executa a aplicação num contentor personalizado no Serviço de Aplicações Azure.
Pré-requisitos
Para concluir este tutorial:
Inscrever numa conta do Docker Hub
Instale o Docker para Windows.
Mude o Docker para executar contentores do Windows.
Instale o Visual Studio 2019 com o ASP.NET e desenvolvimento web e cargas de trabalho de
desenvolvimento azure. Se já instalou o Visual Studio 2019:
Atualizações .
Adicione as cargas de trabalho no Estúdio Visual selecionando Ferramentas > Get Tools e Recursos .
Criar uma aplicação Web ASP.NET

Crie uma aplicação web ASP.NET seguindo estes passos:
1. Abra o Estúdio Visual e, em seguida, selecione Criar um novo projeto .
2. Em Criar um novo projeto, encontre e escolha ASP.NET Aplicação Web (.QUADRO NET) para C#, em
seguida, selecione Next .
3. No Configure o seu novo projeto, nomeie a aplicação myFirstAzureWebApp, e depois selecione Create .
4. Pode implementar qualquer tipo de aplicação Web ASP.NET no Azure. Para este arranque rápido, escolha o
modelo MVC.
5. Selecione supor te Docker , e certifique-se de que a autenticação está definida para não autenticação .
Selecione Criar .
6. Se o ficheiro Dockerfile não se abrir automaticamente, abra-o a partir do Explorador de Soluções .

7. Precisa de uma imagem de pai apoiada. Altere a imagem principal, substituindo a linha FROM pelo código
seguinte e guarde o ficheiro:
FROM mcr.microsoft.com/dotnet/framework/aspnet:4.7.2-windowsservercore-ltsc2019
8. A partir do menu do Estúdio Visual, selecione Debug > Star t Without Debugging para executar a
Publicar no Hub do Docker

1. No Solution Explorer, clique à direita no projeto myFirstAzureWebApp e selecione Publish .
2. Escolha o Ser viço de Aplicações e, em seguida, selecione Publicar .
3. Em Pick a publish target , selecione Registo de Contentores e Docker Hub , e, em seguida, clique em
Publicar .
4. Forneça as credenciais da sua conta Docker Hub e selecione Save .
Aguarde pela conclusão da implementação. A página Publish mostra agora o nome do repositório para
usar mais tarde.
5. Copie este nome de repositório para utilizar mais tarde.
Criar uma aplicação de contentor do Windows

1. Inicie sessão no portal do Azure.
2. Selecione Criar um recurso , no canto superior esquerdo do portal do Azure.
3. Na caixa de pesquisa acima da lista de recursos do Azure Marketplace, procure por Web App para
contentores, e selecione Create .
4. Na Web App Create, escolha a sua subscrição e um Grupo de Recursos . Pode criar um novo grupo de
recursos, se necessário.
5. Forneça um nome de aplicativo, como win-container-demo e escolha Windows para Sistema Operativo .
Selecione Seguinte: Docker para continuar.
6. Para Fonte de Imagem , escolha Docker Hub e para Imagem e etiqueta, introduza o nome de repositório
copiado em Publish to Docker Hub.
Se tiver uma imagem personalizada noutra localização para a sua aplicação Web, como no Azure Container
Registry ou noutro repositório privado, pode configurá-la aí.
7. Selecione Rever e Criar e, em seguida, Criar e esperar que o Azure crie os recursos necessários.
Navegar para a aplicação de contentor

Quando a operação do Azure estiver concluída, é apresentada uma caixa de notificação.
1. Clique em Ir para recurso .

2. Na visão geral deste recurso, siga o link ao lado do URL .
Uma nova página do navegador abre para a seguinte página:
Aguarde alguns minutos e tente novamente, até ver a home page de ASP.NET predefinida:
Parabéns! Está a executar o seu primeiro contentor do Windows personalizado no Serviço de Aplicações do
Azure.
Ver os registos de arranque do contentor

O contentor do Windows poderá demorar algum tempo até ser carregado. Para ver o progresso, navegue para *
<* o seguinte URL substituindo app_name>com o nome da sua aplicação.
https://<app_name>.scm.azurewebsites.net/api/logstream
Os registos transmitidos têm o seguinte aspeto:

2018-07-27T12:03:11 Welcome, you are now connected to log-streaming service.
27/07/2018 12:04:10.978 INFO - Site: win-container-demo - Start container succeeded. Container:
facbf6cb214de86e58557a6d073396f640bbe2fdec88f8368695c8d1331fc94b
27/07/2018 12:04:16.767 INFO - Site: win-container-demo - Container start complete
27/07/2018 12:05:05.017 INFO - Site: win-container-demo - Container start complete
27/07/2018 12:05:05.020 INFO - Site: win-container-demo - Container started successfully
Atualizar localmente e reimplementar

1. No Estúdio Visual, no Solution Explorer, abra views > home > index.cshtml .
2. Localize a etiqueta HTML <div class="jumbotron"> na parte superior e substitua todo o elemento pelo
código seguinte:
<p class="lead">This is a simple app that we've built that demonstrates how to deploy a .NET app to
Azure App Service.</p>
</div>
3. Para reimplantar para o Azure, clique à direita no projeto myFirstAzureWebApp no Solution Explorer e
escolha Publicar .
4. Na página de publicação, selecione Publicar e aguarde até a publicação estar concluída.
5. Para dizer ao Serviço de Aplicações para obter a nova imagem do Hub do Docker, reinicie a aplicação. De
volta à página da aplicação no portal, clique em Reiniciar > Sim .
Navegue novamente para a aplicação de contentor. Quando atualiza a página Web, primeiro, a aplicação deve
reverter para a página "A Iniciar" e, em seguida, volta a apresentar a página Web atualizada ao fim de alguns
minutos.
Utilizar uma imagem principal diferente
Você é livre de usar uma imagem personalizada do Docker diferente para executar a sua aplicação. No entanto,
deve escolher a imagem dos pais (imagem base) certa para o quadro que deseja:
Para implementar aplicações .NET Framework, utilize uma imagem dos pais com base na versão do Canal de
Manutenção de Longo Prazo (LTSC) do Windows Server Core 2019.
Para implementar aplicações .NET Core, utilize uma imagem dos pais com base na versão do Canal de
Assistência Semi-Anual (SAC) do Windows Server Nano 1809.
O carregamento das imagens principais durante o arranque da aplicação demora algum tempo. No entanto, pode
utilizar uma das seguintes imagens principais que já estão em cache no Serviço de Aplicações do Azure para
reduzir o tempo de arranque:
mcr.microsoft.com/dotnet/framework/aspnet:4.7.2 windowsservercore-ltsc2019
mcr.microsoft.com/windows/nanoserver:1809 - esta imagem é o recipiente base utilizado em imagens do
Microsoft ASP.NET Core Microsoft Windows Nano Server.
Passos seguintes
Migrar para o contentor do Windows no Azure
Tutorial: Construir uma aplicação de base de dados
core e SQL de ASP.NET no Azure App Service
NOTE
Este artigo implementa uma aplicação no Serviço de Aplicações no Windows. Para implementar no Serviço de Aplicações
em Linux, consulte construir uma aplicação de base de dados .NET Core e SQL em Azure App Service no Linux.
O Serviço de Aplicações oferece um serviço de alojamento na Web altamente dimensionável e com correção
automática no Azure. Este tutorial mostra como criar uma aplicação .NET Core e conectá-la à Base de Dados SQL.
Quando terminar, terá uma aplicação de MVC .NET Core em execução no Serviço de Aplicações.
Neste tutorial, vai aprender a:

Criar uma base de dados na Base de Dados Azure SQL
Ligar uma aplicação .NET Core à Base de Dados SQL
Atualizar o modelo de dados e voltar a implementar a aplicação
Transmitir os registos de diagnóstico em fluxo a partir do Azure
Gerir a aplicação no portal do Azure
Pré-requisitos
Instalar o Git
Instale o mais recente .NET Core 3.1 SDK
Criar uma aplicação .NET Core local
Neste passo, vai configurar o projeto .NET Core local.
Clonar a aplicação de exemplo
Na janela de terminal, cd num diretório de trabalho.
Execute os seguintes comandos para clonar o repositório de exemplo e alterar para a respetiva raiz.
git clone https://github.com/azure-samples/dotnetcore-sqldb-tutorial

cd dotnetcore-sqldb-tutorial
O projeto de exemplo contém uma aplicação CRUD (create-read-update-delete) básica com o Entity Framework
Core.
Executar a aplicação
Execute os seguintes comandos para instalar os pacotes necessários, executar migrações de base de dados e
iniciar a aplicação.
dotnet tool install -g dotnet-ef

dotnet ef database update
dotnet run
Navegue para http://localhost:5000 num browser. Selecione a ligação Criar Novo e criar alguns itens a fazer.
Para parar o .NET Core em qualquer altura, prima Ctrl+C no terminal.

comandos pré-instalados do Cloud Shell para executar o código neste artigo sem ter de instalar nada no
ambiente local.





Neste passo, cria-se uma base de dados na Base de Dados Azure SQL. Quando a sua aplicação é implantada no
Azure, utiliza esta base de dados.
Criar um servidor na Base de Dados Azure SQL
Na Cloud Shell, crie um servidor na Base de Dados Azure SQL com o az sql server create comando. Um
servidor é uma construção lógica que contém um grupo de bases de dados geridas como um grupo.
Substitua o <server-name> espaço reservado por um nome único. Este nome é usado como parte do ponto final
globalmente único SQL Database, <server-name>.database.windows.net . Os caracteres válidos a - z 0 - 9
são, . - . . Além disso, substitua <db-username> e por um nome de utilizador e senha à sua <db-password>
escolha.
az sql server create --name <server-name> --resource-group myResourceGroup --location "West Europe" --admin-
user <db-username> --admin-password <db-password>
Quando o servidor é criado, o Azure CLI mostra informações semelhantes ao seguinte exemplo:
{
"administratorLogin": "<db-username>",
"administratorLoginPassword": null,
"fullyQualifiedDomainName": "<server-name>.database.windows.net",
"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Sql/servers/<server-name>",
"identity": null,
"kind": "v12.0",
"name": "<server-name>",
"resourceGroup": "myResourceGroup",
"state": "Ready",
"tags": null,
"type": "Microsoft.Sql/servers",
"version": "12.0"
}
Configurar uma regra de firewall do servidor

Crie uma regra de firewall ao nível do servidor utilizando o az sql server firewall create comando. Quando os
IPs inicial e final estão definidos como 0.0.0.0, a firewall apenas é aberta para outros recursos do Azure.
az sql server firewall-rule create --resource-group myResourceGroup --server <server-name> --name

AllowAzureIps --start-ip-address 0.0.0.0 --end-ip-address 0.0.0.0
TIP
Pode ser ainda mais restritivo na sua regra de firewall ao utilizar apenas os endereços IP de saída que a aplicação utiliza.
Na Cloud Shell, volte a executar o comando para permitir o acesso a partir do seu computador local, substituindo
<your-ip-address> o seu endereço IP IPv4 local.
az sql server firewall-rule create --name AllowLocalClient --server <server_name> --resource-group

myResourceGroup --start-ip-address=<your-ip-address> --end-ip-address=<your-ip-address>

Crie uma base de dados com um nível de desempenho S0 no servidor com o comando az sql db create .
az sql db create --resource-group myResourceGroup --server <server-name> --name coreDB --service-objective S0
Criar uma cadeia de ligação

Obtenha a cadeia de ligação usando o az sql db show-connection-string comando.
az sql db show-connection-string --client ado.net --server <server-name> --name coreDB
Na saída de comando, <username> substitua- e com as <password> credenciais de administrador de base de

dados que usou anteriormente.
Esta é a cadeia de ligação para a sua aplicação .NET Core. Copie-a para utilizar mais tarde.
Configure app para ligar à base de dados em Azure
No seu repositório local, abra Startup.cs e localize o seguinte código:
services.AddDbContext<MyDatabaseContext>(options =>
options.UseSqlite("Data Source=localdatabase.db"));
Substitua-o pelo seguinte código.
services.AddDbContext<MyDatabaseContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("MyDbConnection")));
IMPORTANT
Para aplicações de produção que precisam de escalar, siga as melhores práticas na aplicação de migrações na produção.
Executar migrações de base de dados para a base de dados em Azure

A sua aplicação está atualmente ligada a uma base de dados local do Sqlite. Agora que configuraste uma Base de
Dados Azure SQL, recria a migração inicial para a segmentar.
A partir da raiz do repositório, executar os seguintes comandos. <connection-string> Substitua-a pela cadeia de
ligação que criou anteriormente.
# Delete old migrations

rm Migrations -r
# Recreate migrations
dotnet ef migrations add InitialCreate
# Set connection string to production database

# PowerShell
$env:ConnectionStrings:MyDbConnection="<connection-string>"
# CMD (no quotes)
set ConnectionStrings:MyDbConnection=<connection-string>
# Bash (no quotes)
export ConnectionStrings__MyDbConnection=<connection-string>
# Run migrations
Executar app com nova configuração

Agora que as migrações na base de dados são executadas na base de dados de produção, teste a sua aplicação
executando:
dotnet run
Navegue para http://localhost:5000 num browser. Selecione a ligação Criar Novo e criar alguns itens a fazer. A
sua aplicação está agora a ler e a escrever dados para a base de dados de produção.
Cometa as suas mudanças locais e, em seguida, comprometa-a no seu repositório git.
git add .
git commit -m "connect to SQLDB in Azure"
Está pronto para implementar o seu código.

Neste passo, vai implementar a aplicação .NET Core ligada à Base de Dados SQL no Serviço de Aplicações.
Configurar a implementação do git local
O nome de utilizador deve ser único dentro do Azure e, para os pushs git locais, não deve conter o símbolo
'@'.
Crie um plano do Serviço de Aplicações
seguinte exemplo:
{
"kind": "app",
}
Crie uma aplicação web no plano de myAppServicePlan Serviço de Aplicações.
Na Cloud Shell, podes az webapp create usar o comando. No exemplo a seguir, substitua <app-name> com um
nome de aplicação globalmente exclusivo (os carateres válidos são a-z , 0-9 e - ).
az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name <app-name> --deployment-

local-git

name>.git'
{
"clientCertExclusionPaths": null,
"containerSize": 0,
"deploymentLocalGitUrl": "https://<username>@<app-name>.scm.azurewebsites.net/<app-name>.git",
"enabled": true,
}
NOTE
dele mais tarde.
Cadeia de ligação configurada

Para definir as cordas de ligação para a sua aplicação Azure, utilize o az webapp config appsettings set comando
na Cloud Shell. No comando seguinte, <app-name> substitua, bem como o parâmetro com a cadeia de
<connection-string> ligação que criou anteriormente.
az webapp config connection-string set --resource-group myResourceGroup --name <app-name> --settings

MyDbConnection="<connection-string>" --connection-string-type SQLAzure
Em ASP.NET Core, pode utilizar esta cadeia de conexão denominada ( MyDbConnection ) utilizando o padrão
padrão, como qualquer cadeia de conexão especificada em appsettings.json. Neste caso, MyDbConnection também
é definido no seu appsettings.json. Ao executar no Serviço de Aplicações, a cadeia de ligação definida no Serviço
de Aplicações tem precedência sobre a cadeia de ligação definida nas suas appsettings.json. O código utiliza o
valor appsettings.json durante o desenvolvimento local, e o mesmo código utiliza o valor do Serviço de
Aplicações quando implementado.
Para ver como a cadeia de ligação é referenciada no seu código, consulte a aplicação Configure para ligar à base
de dados de produção.
web.
exemplo seguinte:
Enumerating objects: 268, done.

Counting objects: 100% (268/268), done.
Writing objects: 100% (268/268), 1.18 MiB | 1.55 MiB/s, done.
Total 268 (delta 95), reused 251 (delta 87), pack-reused 0
remote: Resolving deltas: 100% (95/95), done.
remote: Preparing deployment for commit id '64821c3558'.
remote: Project file path: .\DotNetCoreSqlDb.csproj
remote: Generating deployment script for ASP.NET MSBuild16 App
remote: Generated deployment script files
remote: Handling ASP.NET Core Web Application deployment with MSBuild16.
remote: .
remote: .
remote: .
remote: Triggering recycle (preview mode disabled).
remote: App container will begin restart within 10 seconds.
To https://<app-name>.scm.azurewebsites.net/<app-name>.git
* [new branch] master -> master
Navegue pela app Azure

Navegue pela aplicação implementada utilizando o seu navegador web.
http://<app-name>.azurewebsites.net
Adicione alguns itens a fazer.

Parabéns! Está a executar uma aplicação .NET Core condicionada por dados no Serviço de Aplicações.
Atualizar localmente e reimplementar

Neste passo, vai fazer uma alteração ao esquema da base de dados e publicá-lo no Azure.
Atualizar o modelo de dados
Abra Models\Todo.cs no editor de código. Adicione a seguinte propriedade à classe ToDo :
public bool Done { get; set; }
Rerun migrações de base de dados

Executar alguns comandos para fazer atualizações para a base de dados de produção.
dotnet ef migrations add AddProperty

Utilizar a nova propriedade

Faça algumas alterações no seu código para utilizar a propriedade Done . Para simplificar, neste tutorial, apenas
vai alterar as vistas Index e Create para ver a propriedade em ação.
Abra Controllers\TodosController.cs.
Localize o método Create([Bind("ID,Description,CreatedDate")] Todo todo) e adicione Done à lista de
propriedades no atributo Bind . Quando terminar, a assinatura do método Create() é semelhante ao seguinte
código:
public async Task<IActionResult> Create([Bind("ID,Description,CreatedDate,Done")] Todo todo)
Abra Views\Todos\Create.cshtml.
No código Razor, deverá ver um elemento <div class="form-group"> para Description e outro elemento
<div class="form-group"> para CreatedDate . Imediatamente a seguir a estes dois elementos, adicione outro
elemento <div class="form-group"> para Done :
<div class="form-group">
<label asp-for="Done" class="col-md-2 control-label"></label>
<div class="col-md-10">
<input asp-for="Done" class="form-control" />
<span asp-validation-for="Done" class="text-danger"></span>
</div>
</div>
Abra Views\Todos\Index.cshtml.
Procure o elemento <th></th> vazio. Imediatamente acima deste elemento, adicione o seguinte código Razor:
<th>
@Html.DisplayNameFor(model => model.Done)
</th>
Localize o elemento <td> que contém os programas auxiliares da etiqueta asp-action . Imediatamente acima
deste elemento, adicione o seguinte código Razor:
<td>
@Html.DisplayFor(modelItem => item.Done)
</td>
É tudo o que precisa para ver as alterações nas vistas Index e Create .
Testar as alterações localmente
Execute a aplicação localmente.
dotnet run
No seu browser, navegue até http://localhost:5000/ . Agora, pode adicionar um item a fazer e marcar
Concluído . Em seguida, deve ser apresentado na sua home page como um item concluído. Lembre-se de que a
vista Edit não apresenta o campo Done , porque a vista Edit não foi alterada.
Publicar alterações no Azure
git add .
git commit -m "added done field"
Uma vez git push concluída, navegue na sua aplicação De Serviço de Aplicações e tente adicionar um item a
fazer e verifique 'Feito'.
Todos os itens a fazer existentes continuam a ser apresentados. Quando republicar a sua aplicação Core ASP.NET,
os dados existentes na base de dados SQL não se perdem. Além disso, as Migrações do Entity Framework Core
apenas alteram o esquema de dados e mantêm os dados existentes intactos.
Transmitir registos de diagnóstico em fluxo

Enquanto a aplicação core ASP.NET é executada no Azure App Service, pode obter os registos de consola
canalizados para a Cloud Shell. Dessa forma, pode obter as mesmas mensagens de diagnóstico para ajudar a
depurar erros de aplicações.
O projeto da amostra já segue a orientação em ASP.NET Core Logging in Azure com duas alterações de
configuração:
Inclui uma referência a Microsoft.Extensions.Logging.AzureAppServices DotNetCoreSqlDb.csproj.
Chamadas loggerFactory.AddAzureWebAppDiagnostics() em Program.cs.
Para definir o nível de registo de ASP.NET Core no Serviço de Aplicações para Information a partir do nível
predefinido, Error utilize o comando na Cloud az webapp log config Shell.
az webapp log config --name <app-name> --resource-group myResourceGroup --application-logging true --level
information
NOTE
O nível de registo do projeto já está definido para Information appsettings.json.
Para iniciar o streaming de registos, utilize o az webapp log tail comando na Cloud Shell.
az webapp log tail --name <app-name> --resource-group myResourceGroup
Uma vez iniciado o streaming de registos, refresque a app Azure no navegador para obter algum tráfego web.
Verá então os registos da consola direcionados para o terminal. Se não vir os registos da consola imediatamente,
volte a consultar dentro de 30 segundos.
Para parar o streaming de registo a qualquer momento, escreva Ctrl + C .
Para obter mais informações sobre a personalização dos registos do Núcleo de ASP.NET, consulte iniciar sessão no
ASP.NET Core.
Gerencie a sua app Azure

Para ver a aplicação que criou, no portal Azure,procure e selecione Ser viços de Aplicações.
Na página Ser viços de Aplicações, selecione o nome da sua aplicação Azure.

Por predefinição, o portal mostra a página geral da sua aplicação. Esta página proporciona-lhe uma vista do
desempenho da aplicação. Aqui, também pode realizar tarefas de gestão básicas, como navegar, parar, iniciar,
reiniciar e eliminar. Os separadores no lado esquerdo da página mostram as várias páginas de configuração que
pode abrir.
Limpar recursos
Passos seguintes
O que aprendeu:
Ligar uma aplicação .NET Core à Base de Dados SQL
Transmitir os registos do Azure para o seu terminal
Avance para o próximo tutorial para aprender a mapear um nome DNS personalizado para a sua aplicação.
Tutorial: Mapeie o nome DNS personalizado para a sua aplicação
Tutorial: Implemente uma app ASP.NET para O
Azure com base de dados Azure SQL
correção automática. Este tutorial mostra-lhe como implementar uma aplicação de ASP.NET baseada em dados no
Serviço de Aplicações e conectá-la à Base de Dados Azure SQL. Quando terminar, tem uma aplicação ASP.NET em
funcionamento em Azure e ligada à Base de Dados SQL.
Neste tutorial, ficará a saber como:

Ligar uma aplicação ASP.NET à Base de Dados SQL
Pré-requisitos
Instale o Visual Studio 2019 com a carga de trabalho de ASP.NET e desenvolvimento web.
Se já instalou o Estúdio Visual, adicione as cargas Tools de trabalho no Estúdio Visual clicando em >
Ferramentas Get Tools e Recursos .
Transfira o projeto de exemplo.
Extrato (unzip) o ficheiro dotnet-sqldb-tutorial-master.zip.
O projeto de exemplo contém uma aplicação básica ASP.NET MVC create-read-update-delete - criar-ler-atualizar-
eliminar (CRUD) que utiliza o Entity Framework Code First.
Abra o ficheiro dotnet-sqldb-tutorial-master/DotNetAppSqlDb.sln no Visual Studio.
Escreva Ctrl+F5 para executar a aplicação sem a depurar. A aplicação é apresentada no browser predefinido.
Selecione a ligação Criar Novo e criar alguns itens a fazer.
Teste as ligações Editar , Detalhes e Eliminar .

A aplicação utiliza um contexto de base de dados para se ligar à base de dados. Neste exemplo, o contexto de base
de dados utiliza uma cadeia de ligação com o nome MyDbConnection . A cadeia de ligação é definida no ficheiro
Web.config e é referenciado no ficheiro Models/MyDatabaseContext.cs. O nome da corda de ligação é usado mais
tarde no tutorial para ligar a aplicação Azure a uma Base de Dados Azure SQL.
Publicar ASP.NET aplicação ao Azure

No Explorador de Soluções , clique com o botão direito do rato no projeto DotNetAppSqlDb e selecione
Publicar .
Certifique-se de que o Ser viço de Aplicações do Microsoft Azure está selecionado e clique em Publicar .
A publicação abre o diálogo Create App Ser vice, que o ajuda a criar todos os recursos Azure que precisa para
executar a sua app ASP.NET em Azure.
Iniciar sessão no Azure
Na caixa de diálogo Criar Ser viço de Aplicações , clique em Adicionar uma conta e inicie sessão na sua
subscrição do Azure. Se já tiver sessão iniciada numa conta Microsoft, confirme que esta inclui a sua subscrição do
Azure. Se a subscrição do Azure não estiver na conta Microsoft em que tem sessão iniciada, clique nesta para
adicionar a conta correta.
NOTE
Se já tiver sessão iniciada, não selecione ainda Criar .
Configurar o nome da aplicação Web
Pode manter o nome da aplicação Web gerado ou alterá-lo para outro nome exclusivo (os carateres válidos são
a-z , 0-9 e - ). O nome da aplicação Web é utilizado como parte do URL predefinido da sua aplicação (
<app_name>.azurewebsites.net , onde <app_name> é o nome da aplicação Web). O nome da aplicação Web tem de
ser exclusivo em todas as aplicações no Azure.
1. Junto a Grupo de recursos , clique em Novo .
2. Dê o nome myResourceGroup ao grupo de recursos.
Um plano do serviço de aplicações especifica o local, tamanho e funcionalidades da farm de servidores Web que
aloja a aplicação. Pode economizar dinheiro ao alojar várias aplicações, configurando as aplicações Web para
partilhar um único plano do serviço de aplicações.
Os planos do Serviço de Aplicações definem:
Região (por exemplo: Europa do Norte, E.U.A. Leste, Ásia Sudeste)
Tamanho da instância (pequena, média, grande)
Contagem do dimensionamento (1 a 20 instâncias)
SKU (Gratuito, Partilhado, Básico, Standard ou Premium)
1. Junto a Plano do Ser viço de Aplicações , clique em Novo .
2. Na caixa de diálogo Configurar o Plano do Ser viço de Aplicações , configure o plano novo com as
definições seguintes:
DEF IN IÇ Ã O VA LO R SUGERIDO PA RA O BT ER M A IS IN F O RM A Ç Õ ES:
Plano de Ser viço de Aplicações myAppServicePlan Planos do Serviço de Aplicações
Localização Europa ocidental Regiões do Azure
Tamanho Gratuito Escalões de preço
Criar um servidor
Antes de criar uma base de dados, precisa de um servidor SQL lógico. Um servidor lógico SQL é uma construção
lógica que contém um grupo de bases de dados geridas como um grupo.
1. Clique em Criar uma Base de Dados SQL .
2. Na caixa de diálogo Configurar Base de Dados SQL , clique em Nova junto a SQL Ser ver .
É gerado um nome de servidor exclusivo. Este nome é usado como parte do URL predefinido para o seu
servidor, <server_name>.database.windows.net . Deve ser único em todos os servidores do Azure SQL. Pode
alterar o nome do servidor, mas, para este tutorial, mantenha o valor gerado.
3. Adicione um nome de utilizador e uma palavra-passe de administrador. Para saber os requisitos de
complexidade das palavras-passe, veja Password Policy (Política de Palavras-passe).
Memorize o nome de utilizador e a palavra-passe. Precisas deles para gerir o servidor mais tarde.
IMPORTANT
Embora a palavra-passe nas cadeias de ligação esteja ocultada (no Visual Studio e também no Serviço de
Aplicações), o facto de ser mantida algures aumenta a superfície de ataque da sua aplicação. O Serviço de Aplicações
pode utilizar identidades de serviço geridas para eliminar este risco ao remover a necessidade de manter segredos
na configuração do código ou da aplicação. Para obter mais informações, veja Passos seguintes.
4. Clique em OK . Não feche já a caixa de diálogo Configurar Base de Dados SQL .
1. Na caixa de diálogo Configurar Base de Dados SQL :
Mantenha o Nome da Base de Dados predefinido gerado.
Em Nome da Cadeia de Ligação , escreva MyDbConnection. Este nome tem de corresponder à cadeia
de ligação que é referenciada em Models/MyDatabaseContext.cs.
Selecione OK .
2. A caixa de diálogo Criar Ser viço de Aplicações mostra os recursos que configurou. Clique em Criar .
Quando o assistente concluir a criação dos recursos do Azure, publica a aplicação ASP.NET no Azure. O seu
browser é iniciado com o URL para a aplicação implementada.
Adicione alguns itens a fazer.
Parabéns! A aplicação ASP.NET condicionada por dados está em execução no Serviço de Aplicações do Azure.
Aceda à base de dados localmente

O Visual Studio permite-lhe explorar e gerir facilmente a sua nova base de dados no SQL Ser ver Object
Explorer .
Criar uma ligação à base de dados
No menu Ver , selecione SQL Ser ver Object Explorer .
Na parte superior do SQL Ser ver Object Explorer , clique no botão Adicionar SQL Ser ver .
Configurar a ligação à base de dados
Na caixa de diálogo Ligar , expanda o nó Azure . São apresentadas aqui todas as suas instâncias da Base de Dados
SQL no Azure.
Selecione a base de dados que criou anteriormente. A ligação que criou anteriormente é preenchida
automaticamente na parte inferior.
Escreva a palavra-passe de administrador da base de dados que criou acima e clique em Ligar .
Permitir a ligação de cliente a partir do computador
É aberta a caixa de diálogo Criar uma regra de firewall nova . Por padrão, um servidor apenas permite
ligações às suas bases de dados a partir de serviços Azure, como a sua aplicação Azure. Para ligar à sua base de
dados de fora do Azure, crie uma regra de firewall ao nível do servidor. A regra de firewall permite o endereço IP
público do seu computador local.
A caixa de diálogo já está preenchida com o endereço IP público do seu computador.
Certifique-se de que Adicionar o meu IP de cliente está selecionado e clique em OK .
Quando o Visual Studio concluir a criação da definição de firewall para a sua instância da Base de Dados SQL, a
ligação aparece em SQL Ser ver Object Explorer .
Aqui, pode realizar as operações mais comuns de bases de dados, como executar consultas, criar vistas e
procedimentos armazenados, entre outras.
Expandir a sua ligação > Bases de dados a sua base de dados > ** <>** > Tabelas . Clique com o botão direito
do rato na tabela Todoes e selecione Ver Dados .
Atualizar a aplicação com Migrações Code First

Pode utilizar as ferramentas familiares no Estúdio Visual para atualizar a sua base de dados e aplicação no Azure.
Neste passo, vai utilizar Migrações First Code em Entity Framework para fazer uma alteração ao esquema da base
de dados e publicá-la no Azure.
Para obter mais informações sobre como utilizar o Entity Framework Code First Migrations, veja Getting Started
with Entity Framework 6 Code First using MVC 5 (Introdução a Entity Framework 6 Code First com MVC 5).
Abra Models\Todo.cs no editor de código. Adicione a seguinte propriedade à classe ToDo :
public bool Done { get; set; }
Executar Primeiras Migrações de Código localmente

Execute alguns comandos para fazer atualizações à base de dados local.
No menu Ferramentas , clique em Gestor de Pacotes NuGet > Consola do Gestor de Pacotes .
Na janela da Consola do Gestor de Pacotes, ative as Migrações Code First:
Enable-Migrations
Adicione uma migração:
Add-Migration AddProperty
Atualize a base de dados local:
Update-Database
Escreva Ctrl+F5 para executar a aplicação. Teste as ligações Editar, Detalhes e Criar.
Se a aplicação for carregada sem erros, as Migrações First Code foram bem-sucedidas. No entanto, a página
continua igual, porque a lógica da aplicação ainda não está a utilizar esta propriedade.
Utilizar a nova propriedade
Faça algumas alterações no seu código para utilizar a propriedade Done . Para simplificar, neste tutorial, apenas vai
alterar as vistas Index e Create para ver a propriedade em ação.
Localize o método Create() na linha 52 e adicione Done à lista de propriedades no atributo Bind . Quando
terminar, a assinatura do método Create() é semelhante ao seguinte código:
public ActionResult Create([Bind(Include = "Description,CreatedDate,Done")] Todo todo)
Abra Views\Todos\Create.cshtml.
No código Razor, deverá ver um elemento <div class="form-group"> que utiliza model.Description e outro
elemento <div class="form-group"> que utiliza model.CreatedDate . Imediatamente a seguir a estes dois
elementos, adicione outro elemento <div class="form-group"> que utilize model.Done :
@Html.LabelFor(model => model.Done, htmlAttributes: new { @class = "control-label col-md-2" })
<div class="col-md-10">
<div class="checkbox">
@Html.EditorFor(model => model.Done)
@Html.ValidationMessageFor(model => model.Done, "", new { @class = "text-danger" })
</div>
</div>
</div>
Abra Views\Todos\Index.cshtml.
Procure o elemento <th></th> vazio. Imediatamente acima deste elemento, adicione o seguinte código Razor:
<th>
@Html.DisplayNameFor(model => model.Done)
</th>
Localize o elemento <td> que contém os métodos do programa auxiliar Html.ActionLink() . Acima deste
elemento <td> , adicione outro elemento <td> com o código Razor seguinte:
<td>
@Html.DisplayFor(modelItem => item.Done)
</td>
É tudo o que precisa para ver as alterações nas vistas Index e Create .
Escreva Ctrl+F5 para executar a aplicação.
Agora, pode adicionar um item a fazer e marcar Concluído . Em seguida, deve ser apresentado na sua home page
como um item concluído. Lembre-se de que a vista Edit não apresenta o campo Done , porque a vista Edit não
foi alterada.
Ativar Migrações First Code no Azure
Agora que a mudança de código funciona, incluindo a migração da base de dados, publica-a na sua aplicação
Azure e atualiza também a sua Base de Dados SQL com código first migrations.
Tal como anteriormente, clique com o botão direito do rato no projeto e selecione Publicar .
Clique em Configurar para abrir as definições de publicação.
No assistente, clique em Seguinte .

Confirme que a cadeia de ligação da Base de Dados SQL está preenchida em MyDatabaseContext
(MyDbConnection) . Poderá ter de selecionar a base de dados myToDoAppDb na lista pendente.
Selecione Executar Migrações Code First (executadas quando a aplicação é iniciada) e clique em
Guardar .
Publicar as alterações
Agora que ativou o Code First Migrations na sua aplicação Azure, publique as alterações de código.
Na página de publicação, clique em Publicar .
Experimente voltar a adicionar itens de tarefas a fazer e selecione Concluído . As tarefas devem agora aparecer na
sua home page como itens concluídos.
Todos os itens a fazer existentes continuam a ser apresentados. Quando voltar a publicar a aplicação ASP.NET, os
dados existentes na Base de Dados SQL não são perdidos. Além disso, as Migrações Code First apenas alteram o
esquema de dados e mantêm os dados existentes intactos.
Transmitir em fluxo registos de aplicações

Pode transmitir mensagens de rastreio diretamente da sua aplicação Azure para o Visual Studio.
Cada ação começa com um método Trace.WriteLine() . Este código é adicionado para lhe mostrar como
adicionar mensagens de rastreio à sua aplicação Azure.
Abrir o Explorador de Servidores
No menu Ver , selecione Explorador de Ser vidores . Pode configurar o registo da sua aplicação Azure no
Ser ver Explorer .
Ativar a transmissão em fluxo de registos
No Explorador de Ser vidores , expanda Azure > Ser viço de Aplicações .
Expanda o grupo de recursos myResourceGroup, que criou quando criou a aplicação Azure pela primeira vez.
Clique na sua aplicação Azure e selecione Ver Registos de Streaming .
Os registos são agora transmitidos em fluxo para a janela Saída .
No entanto, ainda não vai ver nenhuma das mensagens de rastreio. Isto porque, quando seleciona pela primeira
vez os Registos de Streaming de Visualização, a sua aplicação Azure define o nível de rastreio Error para , que
apenas regista eventos de erro (com o Trace.TraceError() método).
Alterar os níveis de rastreio
Para alterar os níveis de rastreio para produzir outras mensagens de rastreio, regresse ao Explorador de
Ser vidores .
Clique novamente na sua aplicação Azure e selecione 'Ver Definições' .
No menu pendente Registo da Aplicação (Sistema de Ficheiros) , selecione Verboso . Clique em Guardar .
TIP
Pode experimentar diferentes níveis de rastreio para ver os tipos de mensagens que são apresentadas para cada nível. Por
exemplo, o nível de Informação inclui todos os registos criados por Trace.TraceInformation() , e , mas não
Trace.TraceWarning() Trace.TraceError() registos criados por Trace.WriteLine() .
No seu navegador, volte a navegar para a sua aplicação em http:// o seu nome de * <
aplicação>.azurewebsites.net,* tente clicar em torno da aplicação de lista a fazer em Azure. As mensagens de
rastreio são agora transmitidas em fluxo para a janela Saída no Visual Studio.
Application: 2017-04-06T23:30:41 PID[8132] Verbose GET /Todos/Index

Application: 2017-04-06T23:30:43 PID[8132] Verbose GET /Todos/Create
Application: 2017-04-06T23:30:53 PID[8132] Verbose POST /Todos/Create
Application: 2017-04-06T23:30:54 PID[8132] Verbose GET /Todos/Index
Parar o registo de transmissão em fluxo

Para parar o serviço de transmissão em fluxo de registos, clique no botão Parar a monitorização na janela
Saída .
Aceda ao portal do Azure para gerir a aplicação Web. Procure e selecione Serviços de Aplicações .
Selecione o nome da sua aplicação Azure.
Aterrou na página da sua aplicação.

Por predefinição, o portal mostra a página Descrição Geral . Esta página proporciona-lhe uma vista do
pode abrir.
Limpar recursos
1. Na página Descrição geral da sua aplicação Web no portal do Azure, selecione a ligação
myResourceGroup em Grupo de recursos .
2. Na página do grupo de recursos, confirme que os recursos apresentados são aqueles que pretende eliminar.
3. Selecione Eliminar , introduza myResourceGroup na caixa de texto e, em seguida, selecione Eliminar .
Passos seguintes
Neste tutorial, ficou a saber como:
Ligar uma aplicação ASP.NET à Base de Dados SQL
Avance para o tutorial seguinte para saber como melhorar facilmente a segurança da sua ligação à Base de Dados
SQL do Azure.
Aceder à Base de Dados SQL em segurança com identidades geridas dos recursos do Azure
Tutorial: Construa uma app PHP e MySQL em Azure
NOTE
Este artigo implementa uma aplicação no Serviço de Aplicações no Windows. Para se implementar no Serviço de Aplicações
no Linux, consulte Construir uma aplicação PHP e MySQL no Azure App Service no Linux.
correção automática. Este tutorial mostra como criar uma aplicação PHP em Azure e conectá-la a uma base de
dados MySQL. Quando terminar, terá uma aplicação Laravel em funcionamento no Azure App Service.

Criar uma base de dados MySQL no Azure
Ligar uma aplicação PHP ao MySQL
Pré-requisitos
Instalar o Git
Instalar o PHP 5.6.4 ou superior
Instalar o Composer
Ative as extensões do PHP seguintes, de que o Laravel precisa: OpenSSL, PDO-MySQL, Mbstring, Tokenizer, XML
Instalar e iniciar o MySQL
Preparar o MySQL local

Neste passo, vai criar uma base de dados no seu servidor MySQL local para utilizar neste tutorial.
Ligar ao servidor MySQL local
Numa janela de terminal, ligue ao seu servidor MySQL local. Pode utilizar esta janela de terminal para executar
todos os comandos deste tutorial.
mysql -u root -p
Se lhe for pedida uma palavra-passe, introduza a palavra-passe da conta root . Se não se lembrar da sua palavra-
passe da conta de raiz, veja MySQL: Como Repor a Palavra-passe de Raiz.
Se o comando for executado com êxito, significa que o servidor MySQL está em execução. Se não, siga os passos
de pós-instalação do MySQL para verificar se o servidor MySQL local é iniciado.
Criar uma base de dados localmente
No comando mysql , crie uma base de dados.
CREATE DATABASE sampledb;
Escreva quit para sair da ligação ao servidor.
quit
Criar uma aplicação PHP localmente

Neste passo, vai obter uma aplicação Laravel de exemplo, configurar a respetiva ligação à base de dados e
executá-la localmente.
Clonar o exemplo
Execute o seguinte comando para clonar o repositório de exemplo.
git clone https://github.com/Azure-Samples/laravel-tasks
cd para o diretório clonado. Instale os pacotes necessários.
cd laravel-tasks
composer install
Configurar a ligação ao MySQL
Na raiz do repositório, crie um ficheiro de texto com o nome .env. Copie as variáveis seguintes para o ficheiro .env.
Substitua _ <_ a root_password>espaço reservado pela palavra-passe do utilizador raiz MySQL.
APP_ENV=local
APP_DEBUG=true
APP_KEY=
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=sampledb
DB_USERNAME=root
DB_PASSWORD=<root_password>
Para obter informações sobre como o Laravel utiliza o ficheiro .env, veja Configuração do Ambiente do Laravel.
Executar o exemplo localmente
Execute migrações de bases de dados Laravel para criar as tabelas de que a aplicação precisa. Para ver que tabelas
são criadas nas migrações, veja o diretório database/migrations no repositório Git.
php artisan migrate
Gere uma chave de aplicação do Laravel nova.
php artisan key:generate
Execute a aplicação.
php artisan serve
Navegue para http://localhost:8000 num browser. Adicione algumas tarefas à página.

Para parar o servidor do PHP, escreva Ctrl + C no terminal.

local.




no macOS.
Criar o MySQL no Azure

Neste passo, vai criar uma base de dados MySQL na Base de Dados do Azure para MySQL. Posteriormente, vai
configurar a aplicação PHP para se ligar a esta base de dados.
Criar um servidor MySQL
Na Cloud Shell, crie um servidor na Base de az mysql server create Dados Azure para mySQL com o comando.
No comando seguinte, substitua um * <* nome de servidor único para o mysql_server_name>espaço reservado,
um nome de utilizador para o * <admin_user>, e uma palavra-passe para o * <admin_password> espaço
reservado. O nome do servidor é utilizado como parte do ponto final do MySQL (
https://<mysql_server_name>.mysql.database.azure.com ), por isso, o nome tem de ser exclusivo em todos os
servidores no Azure.
az mysql server create --resource-group myResourceGroup --name <mysql_server_name> --location "West Europe" --
admin-user <admin_user> --admin-password <admin_password> --sku-name B_Gen5_1
NOTE
Uma vez que existem várias credenciais a considerar neste tutorial, para evitar confusões, --admin-user e
--admin-password estão definidos para valores fictícios. Num ambiente de produção, siga as melhores práticas de
segurança ao escolher um bom nome de utilizador e palavra-passe para o servidor MySQL no Azure.
Quando o servidor MySQL tiver sido criado, a CLI do Azure mostra informações semelhantes às do exemplo
abaixo:
{
"name": "<mysql_server_name>",
"resourceGroup": "myResourceGroup",
"sku": {
"additionalProperties": {},
"capacity": 1,
"family": "Gen5",
"name": "B_Gen5_1",
"size": null,
"tier": "GeneralPurpose"
},
"sslEnforcement": "Enabled",
... +
- < Output has been truncated for readability >
}
Configurar a firewall do servidor

Na Cloud Shell, crie uma regra de firewall para o seu az mysql server firewall-rule create servidor MySQL para
permitir ligações ao cliente utilizando o comando. Quando os IPs inicial e final estão definidos como 0.0.0.0, a
firewall apenas é aberta para outros recursos do Azure.
az mysql server firewall-rule create --name allAzureIPs --server <mysql_server_name> --resource-group

myResourceGroup --start-ip-address 0.0.0.0 --end-ip-address 0.0.0.0
TIP
Pode ser ainda mais restritivo na sua regra de firewall ao utilizar apenas os endereços IP de saída que a aplicação utiliza.
Na Cloud Shell, volte a executar o comando para * <* permitir o acesso ao seu computador local, substituindo
your_ip_address>pelo seu endereço IP IPv4 local.
az mysql server firewall-rule create --name AllowLocalClient --server <mysql_server_name> --resource-group

myResourceGroup --start-ip-address=<your_ip_address> --end-ip-address=<your_ip_address>
Ligar ao servidor MySQL de produção localmente

Na janela de terminal local, ligue ao servidor MySQL no Azure. Utilize o valor especificado _ < _anteriormente para
mysql_server_name>. Quando lhe for pedida uma palavra-passe, utilize a que especificou quando criou a base de
dados no Azure.
mysql -u <admin_user>@<mysql_server_name> -h <mysql_server_name>.mysql.database.azure.com -P 3306 -p<PASSWORD>

--ssl-mode=REQUIRED --ssl-ca=<PATH_TO_PEM>
Criar uma base de dados de produção

No comando mysql , crie uma base de dados.
CREATE DATABASE sampledb;
Criar um utilizador com permissões

Crie um utilizador de base de dados com o nome phpappuser e conceda-lhe todos os privilégios da base de dados
sampledb . Novamente, para maior simplicidade do tutorial, utilize MySQLAzure2017 como palavra-passe.
CREATE USER 'phpappuser' IDENTIFIED BY 'MySQLAzure2017';

GRANT ALL PRIVILEGES ON sampledb.* TO 'phpappuser';
Escreva quit para sair da ligação ao servidor.
quit
Ligar a aplicação ao MySQL do Azure

Neste passo, vai ligar a aplicação PHP à base de dados MySQL que criou na Base de Dados do Azure para MySQL.
Configurar a ligação à base de dados
Na raiz do repositório, crie um ficheiro .env.production e copie as variáveis seguintes para o mesmo. Substitua o _
<_ espaço reservado mysql_server_name>tanto em DB_HOST como em DB_USERNAME.
APP_ENV=production
APP_DEBUG=true
APP_KEY=
DB_CONNECTION=mysql
DB_HOST=<mysql_server_name>.mysql.database.azure.com
DB_DATABASE=sampledb
DB_USERNAME=phpappuser@<mysql_server_name>
DB_PASSWORD=MySQLAzure2017
MYSQL_SSL=true
Guarde as alterações.
TIP
Para proteger as informações da ligação do MySQL, este ficheiro já está excluído do repositório Git (veja .gitignore na raiz do
repositório). Mais tarde, vai aprender a configurar variáveis de ambiente no Serviço de Aplicações para ligar à base de dados
na Base de Dados do Azure para MySQL. Com as variáveis de ambiente, não precisa do ficheiro .env no Serviço de
Aplicações.
Configure certificado TLS/SSL

Por padrão, a Base de Dados Azure para MySQL aplica as ligações TLS dos clientes. Para ligar à sua base de dados
MySQL no Azure, tem de utilizar o certificado .pem fornecido pela Base de Dados do Azure para MySQL.
Abra config/database.php e adicione os parâmetros sslmode e options a connections.mysql , conforme mostrado
no código abaixo.
'mysql' => [
...
'sslmode' => env('DB_SSLMODE', 'prefer'),
'options' => (env('MYSQL_SSL')) ? [
PDO::MYSQL_ATTR_SSL_KEY => '/ssl/BaltimoreCyberTrustRoot.crt.pem',
] : []
],
Neste tutorial, o certificado BaltimoreCyberTrustRoot.crt.pem é fornecido no repositório para sua conveniência.

Testar a aplicação localmente
Execute migrações de bases de dados do Laravel tendo .env.production como o ficheiro de ambiente para criar as
tabelas na sua base de dados MySQL na Base de Dados do Azure para MySQL. Lembre-se de que .env.production
tem as informações da ligação à sua base de dados MySQL no Azure.
php artisan migrate --env=production --force
.env.production ainda não tem uma chave de aplicação válida. Gere uma nova no terminal.
php artisan key:generate --env=production --force
Execute a aplicação de exemplo tendo .env.production como o ficheiro de ambiente.
php artisan serve --env=production
Navegue para http://localhost:8000 . Se a página for carregada sem erros, a aplicação PHP está a ligar-se à base
de dados MySQL no Azure.
Adicione algumas tarefas à página.
Para parar o PHP, escreva Ctrl + C no terminal.

Consolidar as alterações
Execute os comandos Git seguintes para consolidar as alterações:
git add .
git commit -m "database.php updates"
A sua aplicação está pronta para ser implementada.
Neste passo, vai implementar a aplicação PHP ligada ao MySQL no Serviço de Aplicações do Azure.
seguinte exemplo:
{
"kind": "app",
}

nome de aplicação globalmente exclusivo (os carateres válidos são a-z , 0-9 e - ). O runtime está definido como
PHP|7.3 . Para ver todos os tempos de corrida suportados, corra. az webapp list-runtimes --linux
# Bash
# PowerShell

name>.git'
{
"containerSize": 0,
"enabled": true,
}
Criou uma nova aplicação Web vazia, com a implementação de git ativada.
NOTE
dele mais tarde.
Configurar as definições da base de dados

Conforme indicado anteriormente, pode ligar à base de dados MySQL do Azure através de variáveis de ambiente
no Serviço de Aplicações.
No Cloud Shell, as variáveis de ambiente são definidas como definições da aplicação com o comando
az webapp config appsettings set .
O comando seguinte configura as definições da aplicação DB_HOST , DB_DATABASE , DB_USERNAME e DB_PASSWORD .

Substitua o nome de _ <aplicação dos_ espaços reservados>e _ <mysql_server_name>_.
az webapp config appsettings set --name <app_name> --resource-group myResourceGroup --settings DB_HOST="
<mysql_server_name>.mysql.database.azure.com" DB_DATABASE="sampledb"
DB_USERNAME="phpappuser@<mysql_server_name>" DB_PASSWORD="MySQLAzure2017" MYSQL_SSL="true"
Pode utilizar o método getenv do PHP para aceder às definições. O código do Laravel utiliza um wrapper env no
getenv do PHP. Por exemplo, a configuração do MySQL em config/database.php é semelhante ao código abaixo:
'mysql' => [
'driver' => 'mysql',
'host' => env('DB_HOST', 'localhost'),
'database' => env('DB_DATABASE', 'forge'),
'username' => env('DB_USERNAME', 'forge'),
'password' => env('DB_PASSWORD', ''),
...
],
Configurar variáveis de ambiente do Laravel

O Laravel precisa de uma chave de aplicação no Serviço de Aplicações. Pode configurá-la nas definições da
aplicação.
Na janela de terminal local, utilize php artisan para gerar uma chave de aplicação nova sem a guardar em .env.
php artisan key:generate --show
Na Cloud Shell, detete a chave de az webapp config appsettings set aplicação na aplicação App Service utilizando
o comando. Substitua o nome de _ <aplicação dos_ espaços reservados>e _ <outputofphpartisankey:generate>_.
az webapp config appsettings set --name <app_name> --resource-group myResourceGroup --settings APP_KEY="
<output_of_php_artisan_key:generate>" APP_DEBUG="true"
APP_DEBUG="true" diz à Laravel para devolver informações de depuração quando a aplicação implementada
encontra erros. Ao executar uma aplicação de produção, defina-o como false , que é mais seguro.
Definir o caminho de aplicação virtual
Desloque o caminho de aplicação virtual para a aplicação. Este passo é necessário porque o ciclo de vida da
aplicação Laravel começa no diretório public em vez do diretório de raiz da aplicação. Outras arquiteturas PHP
cujo ciclo de vida tem início no diretório de raiz podem funcionar sem configuração manual do caminho de
aplicação virtual.
Na Cloud Shell, desloque o az resource update caminho da aplicação virtual utilizando o comando. Substitua o _
<nome de>_ espaço reservado.
az resource update --name web --resource-group myResourceGroup --namespace Microsoft.Web --resource-type

config --parent sites/<app_name> --set properties.virtualApplications[0].physicalPath="site\wwwroot\public" --
api-version 2015-06-01
Por padrão, o Azure App Service_/_ aponta o caminho de aplicação virtual raiz ( ) para o diretório raiz dos ficheiros
de aplicação implantados (sites\wwwroot).
web.
exemplo seguinte:

remote: Preparing deployment for commit id 'a5e076db9c'.
remote: Running custom deployment command...
...
< Output has been truncated for readability >
NOTE
Poderá reparar que o processo de implementação instala pacotes do Composer no fim. O Serviço de Aplicações não executa
estas automatizações durante a implementação predefinida, pelo que este repositório de exemplo tem três ficheiros
adicionais no diretório de raiz para a permitir:
.deployment – este ficheiro diz ao Serviço de Aplicações para executar bash deploy.sh como o script de
implementação personalizado.
deploy.sh – o script de implementação personalizado. Se revir o ficheiro, verá que executa
php composer.phar install a seguir a npm install .
composer.phar – o gestor de pacotes do Composer.
Pode utilizar esta abordagem para adicionar qualquer passo à sua implementação baseada no Git no Serviço de Aplicações.
Para obter mais informações, veja Script de Implementação Personalizado.
Navegue na app Azure

Navegue para http://<app_name>.azurewebsites.net e adicione algumas tarefas à lista.
Parabéns! Está agora a executar uma Aplicação PHP condicionada por dados no Serviço de Aplicações do Azure.
Atualizar o modelo localmente e reimplementar

Neste passo, vai fazer uma pequena alteração ao modelo de dados task e à aplicação Web e, depois, vai publicá-
la no Azure.
No cenário de tarefas, vai modificar a aplicação de modo a poder marcar uma tarefa como concluída.
Adicionar uma coluna
Na janela de terminal local, navegue para a raiz do repositório Git.
Gere uma migração de base de dados nova para a tabela tasks :
php artisan make:migration add_complete_column --table=tasks
Este comando mostra-lhe o nome do ficheiro de migração que foi gerado. Localize o ficheiro em
database/migrations e abra-o.
Substitua o método up pelo código abaixo:
public function up()

{
Schema::table('tasks', function (Blueprint $table) {
$table->boolean('complete')->default(False);
});
}
O código anterior adiciona uma coluna booleana na tabela tasks , com o nome complete .
Substitua o método down pelo código seguinte na ação de reversão:
public function down()

{
Schema::table('tasks', function (Blueprint $table) {
$table->dropColumn('complete');
});
}
Na janela de terminal local, execute migrações de bases de dados do Laravel para fazer a alteração na base de
dados local.
php artisan migrate
Com base na convenção de nomenclatura do Laravel, o modelo Task (veja app/Task.php) mapeia para a tabela
tasks por predefinição.
Atualizar a lógica da aplicação

Abra o ficheiro routes/web.php. A aplicação define as respetivas rotas e a lógica de negócio aqui.
No fim do ficheiro, adicione uma rota com o código abaixo:
/**
* Toggle Task completeness
*/
Route::post('/task/{id}', function ($id) {
error_log('INFO: post /task/'.$id);
$task = Task::findOrFail($id);
$task->complete = !$task->complete;
$task->save();
return redirect('/');
});
O código anterior faz uma simples atualização ao modelo de dados, ao alternar o valor de complete .
Atualizar a vista
Abra o ficheiro resources/views/tasks.blade.php. Procure o código de início <tr> e substitua-o por:
<tr class="{{ $task->complete ? 'success' : 'active' }}" >
O código anterior altera a cor da linha, dependendo de a tarefa estar concluída ou não.
Na linha seguinte, tem o código abaixo:
<td class="table-text"><div>{{ $task->name }}</div></td>
Substitua a linha anterior pelo código abaixo:

<td>
<form action="{{ url('task/'.$task->id) }}" method="POST">
{{ csrf_field() }}
<button type="submit" class="btn btn-xs">

<i class="fa {{$task->complete ? 'fa-check-square-o' : 'fa-square-o'}}"></i>
</button>
{{ $task->name }}
</form>
</td>
O código anterior adiciona o botão Submeter que referencia a rota que definiu anteriormente.
Na janela de terminal local, execute o servidor de programação a partir do diretório de raiz do repositório Git.
php artisan serve
Para ver a alteração do estado da tarefa, navegue para http://localhost:8000 e selecione a caixa de verificação.
Para parar o PHP, escreva Ctrl + C no terminal.

Na janela de terminal local, execute migrações de bases de dados do Laravel com a cadeia de ligação de produção
para fazer a alteração na base de dados do Azure.
php artisan migrate --env=production --force

Consolide todas as alterações no Git e envie as alterações ao código para o Azure.
git add .
git commit -m "added complete checkbox"
Uma git push vez que esteja completo, navegue para a aplicação Azure e teste a nova funcionalidade.
Se tiver adicionado tarefas, estas são mantidas na base de dados. As atualizações ao esquema de dados não
afetam os dados já existentes.

Enquanto executa a aplicação PHP no Serviço de Aplicações do Azure, pode obter os registos de consola
direcionados para o seu terminal. Dessa forma, pode obter as mesmas mensagens de diagnóstico para ajudar a
Para iniciar o streaming az webapp log tail de registos, utilize o comando na Cloud Shell.
az webapp log tail --name <app_name> --resource-group myResourceGroup
Uma vez iniciado o streaming de log, refresque a aplicação Azure no navegador para obter algum tráfego web.
Verá então os registos da consola direcionados para o terminal. Se não vir os registos da consola imediatamente,
volte a consultar dentro de 30 segundos.
Para parar a transmissão de registos em fluxo em qualquer altura, escreva Ctrl +C.
TIP
Uma aplicação PHP pode utilizar o padrão error_log() como saída para a consola. A aplicação de exemplo utiliza esta
abordagem em app/Http/routes.php.
Como uma arquitetura Web o Laravel utiliza o Monolog como fornecedor de registo. Para ver como o Monolog envia
mensagens para a consola, veja PHP: como utilizar o Monolog para iniciar sessão na consola (php://out).
Gerir a app Azure

Vá ao portal Azure para gerir a app que criou.
A partir do menu esquerdo, clique em Ser viços de Aplicações e, em seguida, clique no nome da sua aplicação
Azure.
Veja a página de visão geral da sua aplicação. Aqui, pode realizar tarefas de gestão básicas, como parar, iniciar,
reiniciar, navegar e eliminar.
O menu do lado esquerdo disponibiliza páginas para configurar a aplicação.
Limpar recursos
Passos seguintes
Criar uma base de dados MySQL no Azure
Ligar uma aplicação PHP ao MySQL
Avance para o tutorial seguinte para aprender a mapear um nome DNS personalizado para a aplicação.
Mapeie um nome dNS personalizado existente para o Serviço de Aplicações Azure
Tutorial: Construa uma app Node.js e MongoDB em
Azure
NOTE
Este artigo implementa uma aplicação no Serviço de Aplicações no Windows. Para se implementar no Serviço de Aplicações
no Linux, consulte Construir uma aplicação Node.js e MongoDB no Azure App Service no Linux.
correção automática. Este tutorial mostra como criar uma aplicação Node.js no App Service e conectá-la a uma
base de dados MongoDB. Quando terminar, terá uma aplicação MEAN (MongoDB, Express, AngularJS e Node.js)
em execução no Serviço de Aplicações do Azure. Para obter simplicidade, a aplicação de exemplo utiliza a estrutura
Web MEAN.js.
O que irá aprender:

Criar uma base de dados MongoDB no Azure
Ligar uma aplicação Node.js ao MongoDB
Pré-requisitos
1. Instalar o Git
2. Instale o Node.js e o NPM
3. Instalar Bower (exigido pelo MEAN.js)
4. Instalar Gulp.js (exigido pelo MEAN.js)
5. Instalar e executar a Edição de Comunidade do MongoDB
Testar MongoDB local

Abra a janela do terminal e cd para o diretório bin da sua instalação do MongoDB. Pode utilizar esta janela de
terminal para executar todos os comandos deste tutorial.
Execute mongo no terminal para ligar ao servidor MongoDB local.
mongo
Se a ligação for bem-sucedida, então a base de dados do MongoDB já está em execução. Caso contrário, certifique-
se de que a base de dados do MongoDB local é iniciada através dos passos indicados em Instalar Edição da
Comunidade do MongoDB. Muitas vezes, mesmo com o MongoDB instalado, continua a precisar de iniciá-lo ao
executar o mongod .
Quando tiver terminado de testar a sua base de dados do MongoDB, escreva Ctrl+C no terminal.
Criar aplicação do Node.js local

Neste passo, vai configurar o projeto Node.js local.
git clone https://github.com/Azure-Samples/meanjs.git
Este repositório de exemplo inclui uma cópia do repositório do MEAN.js. É modificado para ser executado no
Serviço de Aplicações (para obter mais informações, veja o ficheiro README do repositório do MEAN.js).
Execute os seguintes comandos para instalar os pacotes necessários e iniciar a aplicação.
cd meanjs
npm install
npm start
Quando a aplicação estiver totalmente carregada, verá algo semelhante à mensagem seguinte:
--
É MAU. JS - Ambiente de Desenvolvimento
Ambiente: servidor http://0.0.0.0:3000 de desenvolvimento: Base de dados:

mongodb://localhost/mean-dev versão da App: 0.5.0 MEAN. Versão JS: 0.5.0 -
Navegue para http://localhost:3000 num browser. Clique em Inscrever no menu superior e crie um utilizador de
teste.
A aplicação MEAN.js de exemplo armazena os dados do utilizador na base de dados. Se criar um utilizador e iniciar
sessão com êxito, então a aplicação está a escrever dados na base de dados do MongoDB local.
Selecione Administrador > Gerir Ar tigos para adicionar alguns artigos.
Para parar o Node.js em qualquer altura, prima Ctrl+C no terminal.
NOTE
O Início Rápido do Node.js menciona a necessidade de um web.config no diretório da aplicação de raiz. No entanto, neste
tutorial, este ficheiro web.config será automaticamente gerado pelo Serviço de Aplicações ao implementar os ficheiros com a
implementação de Git local em vez da implementação de ficheiros ZIP.

local.




no macOS.
Criar produção do MongoDB

Neste passo, vai criar uma Base de Dados MongoDB no Azure. Quando a aplicação for implementada no Azure,
utiliza esta base de dados na cloud.
Para o MongoDB, este tutorial utiliza o Azure Cosmos DB. O Cosmos DB suporta ligações de cliente do MongoDB.
Criar uma conta do Cosmos DB
NOTE
A criação das bases de dados do Azure Cosmos DB na sua própria subscrição do Azure neste tutorial não acarreta custos.
Para utilizar uma conta gratuita do Azure Cosmos DB durante sete dias, pode utilizar a experiência Experimentar o Azure
Cosmos DB gratuitamente. Basta clicar no botão Criar no mosaico MongoDB para criar uma base de dados do MongoDB
gratuita no Azure. Após a criação da base de dados, navegue para a cadeia de ligação no portal e obtenha a cadeia de
ligação do Azure Cosmos DB para utilizar mais à frente no tutorial.
Na Cloud Shell, crie uma conta az cosmosdb create Cosmos DB com o comando.
No comando seguinte, substitua um nome * <* único cosmos DB para o cosmosdb_name>espaço reservado. Este
nome é utilizado como parte do ponto final do Cosmos DB, https://<cosmosdb_name>.documents.azure.com/ , por
isso, o nome tem de ser exclusivo em todas as contas Cosmos DB no Azure. O nome só pode conter letras
minúsculas, números, o caráter hífen (-) e tem de ter entre três e 50 carateres.
az cosmosdb create --name <cosmosdb_name> --resource-group myResourceGroup --kind MongoDB
O parâmetro --kind MongoDB permite ligações de cliente da MongoDB.

Após criar a conta do Cosmos DB, a CLI do Azure mostra informações semelhantes ao exemplo seguinte:
{
"consistencyPolicy":
{
"defaultConsistencyLevel": "Session",
"maxIntervalInSeconds": 5,
"maxStalenessPrefix": 100
},
"databaseAccountOfferType": "Standard",
"documentEndpoint": "https://<cosmosdb_name>.documents.azure.com:443/",
"failoverPolicies":
...
< Output truncated for readability >
}
Ligar aplicação ao MongoDB de produção

Neste passo, vai ligar a aplicação de exemplo MEAN.js a uma base de dados do Cosmos DB que acabou de criar,
com uma cadeia de ligação do MongoDB.
Obter a chave de base de dados
Para ligar à base de dados do Cosmos DB, precisa da chave da base de dados. Na Cloud Shell,
az cosmosdb list-keys use o comando para recuperar a chave principal.
az cosmosdb list-keys --name <cosmosdb_name> --resource-group myResourceGroup
A CLI do Azure apresenta informações semelhantes ao exemplo seguinte:
{
"primaryMasterKey":
"RS4CmUwzGRASJPMoc0kiEvdnKmxyRILC9BWisAYh3Hq4zBYKr0XQiSE4pqx3UchBeO4QRCzUt1i7w0rOkitoJw==",
"primaryReadonlyMasterKey":
"HvitsjIYz8TwRmIuPEUAALRwqgKOzJUjW22wPL2U8zoMVhGvregBkBk9LdMTxqBgDETSq7obbwZtdeFY7hElTg==",
"secondaryMasterKey":
"Lu9aeZTiXU4PjuuyGBbvS1N9IRG3oegIrIh95U6VOstf9bJiiIpw3IfwSUgQWSEYM3VeEyrhHJ4rn3Ci0vuFqA==",
"secondaryReadonlyMasterKey":
"LpsCicpVZqHRy7qbMgrzbRKjbYCwCKPQRl0QpgReAOxMcggTvxJFA94fTi0oQ7xtxpftTJcXkjTirQ0pT7QFrQ=="
}
Copie o valor de primaryMasterKey . Estas informações são necessárias no passo seguinte.

Configurar a cadeia de ligação na aplicação Node.js
No seu repositório do MEAN.js local, na pasta config/env/, crie um ficheiro denominado local-production.js. Por
predefinição, o .gitignore está configurado para manter este ficheiro fora do repositório.
Copie o código seguinte para o mesmo. Certifique-se de * <* substituir os dois cosmosdb_name>espaços
reservados pelo nome de base de dados Cosmos DB e substituir o * <primary_master_key>* espaço reservado
pela chave que copiou no passo anterior.
module.exports = {
db: {
uri: 'mongodb://<cosmosdb_name>:<primary_master_key>@<cosmosdb_name>.documents.azure.com:10250/mean?
ssl=true&sslverifycertificate=false'
}
};
A ssl=true opção é necessária devido aos requisitos de cadeia de ligação.
Guarde as alterações.
Teste a aplicação no modo de produção
Execute o seguinte comando para minimizar e agrupar scripts para o ambiente de produção. Este processo gera os
ficheiros necessários para o ambiente de produção.
gulp prod
Execute o seguinte comando para utilizar a cadeia de ligação configurada em config/env/local-production.js.
# Bash
NODE_ENV=production node server.js
# Windows PowerShell
$env:NODE_ENV = "production"
node server.js
NODE_ENV=production define a variável de ambiente que informa o Node.js para ser executado no ambiente de
produção. node server.js inicia o servidor do Node.js com server.js na raiz do repositório. Esta é a forma que a
sua aplicação do Node.js é carregada no Azure.
Assim que a aplicação é carregada, certifique-se de que está em execução no ambiente de produção:
--
É MAU. JS
Ambiente: servidor http://0.0.0.0:8443 de produção:<Base>@<>de dados: mongodb://<cosmosdb_name>:

primary_master_key cosmosdb_name .documents.azure.com:10250/mean?ssl=true&versão
sslcheckcertificate=falsa aplicação: 0.5.0 MEAN. Versão JS: 0.5.0
Navegue para http://localhost:8443 num browser. Clique em Inscrever no menu superior e crie um utilizador de
teste. Se criar um utilizador e iniciar sessão com êxito, então a aplicação está a escrever dados na base de dados do
Cosmos DB no Azure.
No terminal, pare o Node.js ao escrever Ctrl+C .

Neste passo, vai implementar a aplicação Node.js ligada ao MongoDB no Serviço de Aplicações do Azure.
seguinte exemplo:
{
"kind": "app",
}

nome de aplicação globalmente exclusivo (os carateres válidos são a-z , 0-9 e - ). O runtime está definido como
NODE|6.9 . Para ver todos os tempos de corrida suportados, corra. az webapp list-runtimes
# Bash
"NODE|6.9" --deployment-local-git
# PowerShell
"NODE|6.9" --deployment-local-git
name>.git'
{
"containerSize": 0,
"enabled": true,
}
Criou uma aplicação Web vazia, com a implementação de git ativada.
NOTE
dele mais tarde.
Configure uma variável de ambiente

Por predefinição, o projeto do MEAN.js mantém o config/env/local-production.js fora do repositório do Git. Assim,
para a sua aplicação Azure, utiliza as definições de aplicativos para definir a sua cadeia de ligação MongoDB.
Para definir as definições da aplicação, utilize o az webapp config appsettings set comando na Cloud Shell.
O exemplo seguinte MONGODB_URI configura uma definição de aplicação na sua aplicação Azure. Substitua os *
<app_name>, * * <cosmosdb_name>* e * <primary_master_key>* espaços reservados.
az webapp config appsettings set --name <app_name> --resource-group myResourceGroup --settings

MONGODB_URI="mongodb://<cosmosdb_name>:<primary_master_key>@<cosmosdb_name>.documents.azure.com:10250/mean?
ssl=true"
No código do Node.js, aceda a esta definição de aplicação com process.env.MONGODB_URI , tal como faria em
qualquer variável de ambiente.
No seu repositório do MEAN.js local, abra config/env/production.js (não config/env/local-production.js), que tem
uma configuração específica de ambiente de produção. A aplicação do MEAN.js predefinida já está configurada
para utilizar a variável de ambiente MONGODB_URI que criou.
db: {
uri: ... || process.env.MONGODB_URI || ...,
...
},

web.

exemplo seguinte:

remote: Preparing deployment for commit id '6c7c716eee'.
remote: Running custom deployment command...
remote: Handling node.js deployment.
.
.
.
To https://<app_name>.scm.azurewebsites.net/<app_name>.git
Poderá reparar que o processo de implementação executa o Gulp depois de npm install . O Serviço de Aplicações
não executa tarefas do Gulp ou do Grunt durante a implementação, pelo que este repositório de exemplo tem dois
ficheiros adicionais no diretório raiz para a permitir:
.implementação - este ficheiro diz ao Serviço de Aplicações para executar bash deploy.sh como o script de
implementação personalizado.
deploy.sh - o script de implementação personalizado. Se vir o ficheiro, verá que executa gulp prod a seguir a
npm install e bower install .
Pode utilizar esta abordagem para adicionar qualquer passo à sua implementação baseada no Git. Se reiniciar a
sua aplicação Azure em algum momento, o Serviço de Aplicações não reexecuta estas tarefas de automação.
Navegue na aplicação implementada utilizando o seu navegador web.
http://<app_name>.azurewebsites.net
Clique em Inscrever no menu superior e crie um utilizador de teste.

Se concluir com êxito e a aplicação iniciar sessão automaticamente no utilizador criado, então a aplicação do
MEAN.js no Azure tem conectividade à base de dados do MongoDB (Cosmos DB).
Selecione Administrador > Gerir Ar tigos para adicionar alguns artigos.
Parabéns! Está a executar uma aplicação Node.js condicionada por dados no Serviço de Aplicações do Azure.
Atualizar o modelo de dados e voltar a implementar

Neste passo, altera o modelo de dados article e publica a sua alteração no Azure.
Abra módules/artigos/servidor/modelos/article.server.model.js.
No ArticleSchema , adicione um tipo String denominado comment . Quando tiver terminado, o código de
esquema deverá este aspeto:
const ArticleSchema = new Schema({

...,
user: {
type: Schema.ObjectId,
ref: 'User'
},
comment: {
type: String,
default: '',
trim: true
}
});
Atualizar o código de artigos

Atualize o resto do seu código articles para utilizar comment .
Existem cinco ficheiros que tem de modificar: o controlador de servidor e as vistas de quatro clientes.
Abra módulos/artigos/servidor/controladores/articles.server.controller.js.
Na função update , adicione uma atribuição de article.comment . O código seguinte mostra a função update
concluída:
exports.update = function (req, res) {
let article = req.article;
article.title = req.body.title;
article.content = req.body.content;
article.comment = req.body.comment;
...
};
Abra modules/artigos/cliente/vistas/view-article.client.view.html.
Exatamente acima da etiqueta de fecho </section> , adicione a seguinte linha para apresentar comment juntamente
com o resto dos dados do artigo:
<p class="lead" ng-bind="vm.article.comment"></p>
Abra modules/artigos/cliente/vistas/list-articles.client.view.html.
Exatamente acima da etiqueta de fecho </a> , adicione a seguinte linha para apresentar comment juntamente com
o resto dos dados do artigo:
<p class="list-group-item-text" ng-bind="article.comment"></p>
Abra módulos/artigos/cliente/vistas/administrador/list-articles.client.view.html.
No interior do elemento comment e imediatamente acima da etiqueta de fecho <div class="list-group"> , adicione
a seguinte linha para apresentar </a> juntamente com o resto dos dados do artigo:
<p class="list-group-item-text" data-ng-bind="article.comment"></p>
Abra módulos/artigos/cliente/vistas/administrador/form-article.client.view.html.
Encontre o elemento <div class="form-group"> que contém o botão para submeter, semelhante ao seguinte:
<button type="submit" class="btn btn-default">{{vm.article._id ? 'Update' : 'Create'}}</button>
</div>
Imediatamente acima desta etiqueta, adicione outro elemento <div class="form-group"> que permite que as
pessoas editem o campo comment . O novo elemento deve ter o seguinte aspeto:
<label class="control-label" for="comment">Comment</label>
<textarea name="comment" data-ng-model="vm.article.comment" id="comment" class="form-control" cols="30"
rows="10" placeholder="Comment"></textarea>
</div>

Guarde todas as alterações.
Na janela do terminal local, teste novamente as alterações no modo de produção.
# Bash
gulp prod
NODE_ENV=production node server.js
# Windows PowerShell
gulp prod
$env:NODE_ENV = "production"
node server.js
Navegue para http://localhost:8443 num browser e certifique-se de que tem sessão iniciada.
Selecione Administrador > Gerir Ar tigos e adicione um artigo ao selecionar o botão + .
Pode ver a nova caixa de texto Comment agora.
No terminal, pare o Node.js ao escrever Ctrl+C .

Na janela terminal local, consolide as suas alterações no Git e envie as alterações ao código para o Azure.
git commit -am "added article comment"

Uma git push vez que esteja completo, navegue para a sua aplicação Azure e experimente a nova funcionalidade.
Se tiver adicionado quaisquer artigos anteriormente, ainda pode vê-los. Os dados existentes no Cosmos DB não se
perdem. Além disso, atualiza o esquema de dados e mantém os dados existentes intactos.

Enquanto executa a aplicação Node.js no Serviço de Aplicações do Azure, pode obter os registos de consola
direcionados para o seu terminal. Dessa forma, pode obter as mesmas mensagens de diagnóstico para ajudar a
Para iniciar o streaming az webapp log tail de registos, utilize o comando na Cloud Shell.
az webapp log tail --name <app_name> --resource-group myResourceGroup
Uma vez iniciado o streaming de log, refresque a sua aplicação Azure no navegador para obter algum tráfego web.
Verá então os registos da consola direcionados para o seu terminal.
Pare a transmissão em fluxo do registo em qualquer altura, ao escrever Ctrl+C .

Vá ao portal Azure para ver a app que criou.
A partir do menu esquerdo, clique em Ser viços de Aplicações e, em seguida, clique no nome da sua aplicação
Azure.
Por padrão, o portal mostra a página de visão geral da sua aplicação. Esta página proporciona-lhe uma vista do
pode abrir.
Limpar recursos
Passos seguintes
O que aprendeu:
Criar uma base de dados MongoDB no Azure
Ligar uma aplicação Node.js ao MongoDB
Avance para o tutorial seguinte para aprender a mapear um nome DNS personalizado para a aplicação.
Migrar uma aplicação ASP.NET para o Serviço de
Aplicações do Azure com um contentor do Windows
(Pré-visualização)
O Serviço de Aplicações do Azure disponibiliza pilhas de aplicações predefinidas no Windows, como ASP.NET ou
Node.js, em execução no IIS. O ambiente pré-configurado do Windows bloqueia o sistema operativo contra acesso
administrativo, instalações de software, alterações ao Global Assembly Cache, etc. (veja Operating system
functionality on Azure App Service (Funcionalidade do sistema operativo no Serviço de Aplicações do Azure). No
entanto, a utilização de um contentor personalizado do Windows no Serviço de Aplicações permite efetuar as
alterações ao SO de que a aplicação precisa, pelo que é fácil migrar uma aplicação no local que requer uma
configuração personalizada do SO e software. Este tutorial demonstra como migrar para o Serviço de Aplicações
uma aplicação ASP.NET que utiliza tipos de letra personalizados instalados na biblioteca de tipos de letra do
Windows. Implemente uma imagem do Windows configurada e personalizada do Visual Studio no Azure
Container Registry, e, em seguida, execute-a no Serviço de Aplicações.
Pré-requisitos
Inscrever numa conta do Docker Hub
Instale o Docker para Windows.
Mude o Docker para executar contentores do Windows.
Instale o Visual Studio 2019 com o ASP.NET e desenvolvimento web e cargas de trabalho de
desenvolvimento azure. Se já instalou o Visual Studio 2019:
Instale as últimas atualizações no Estúdio Visual clicando em Procurar > Atualizações .
Adicione as cargas de trabalho no Estúdio Visual clicando em Ferramentas > Get Tools e Recursos .
Configurar a aplicação localmente

Neste passo, vai configurar o projeto .NET local.
Transfira o projeto de exemplo.
Extraia (deszipe) o ficheiro custom-font-win-container.zip.
O projeto de exemplo contém uma aplicação ASP.NET simples que utiliza um tipo de letra personalizado que está
instalado na biblioteca de tipos de letra do Windows. Não é necessário instalar os tipos de letra, mas é um exemplo
de uma aplicação que está integrada no SO subjacente. Para migrar uma aplicação como esta para o Serviço de
Aplicações, rearquitete o seu código para remover a integração, ou migre-a tal como está num contentor
personalizado do Windows.
Instalar o tipo de letra
No Explorador do Windows, navegue para custom-font-win-container-master/CustomFontSample, clique com o
botão direito do rato em FrederickatheGreat-Regular.ttf e selecione Instalar .
Este tipo de letra está disponível publicamente em Tipos de Letra do Google.
Abra o ficheiro custom-font-win-container/CustomFontSample.sln no Visual Studio.
Escreva Ctrl+F5 para executar a aplicação sem a depurar. A aplicação é apresentada no browser predefinido.
Uma vez que a aplicação utiliza um tipo de letra instalado, não é possível executá-la na sandbox do Serviço de
Aplicações. No entanto, pode implementá-la com um contentor do Windows em alternativa, pois pode instalar o
tipo de letra no contentor do Windows.
Configurar o contentor do Windows
No Explorador de Soluções, clique com o botão direito do rato no projeto CustomFontSample e selecione
Adicionar > Supor te de Orquestração de Contentores .
Selecione Docker Compor > OK .
O projeto está agora configurado para ser executado num contentor do Windows. Um Dockerfile é adicionado ao
projeto CustomFontSample e um projeto docker-compose é adicionado à solução.
No Explorador de Soluções, abra Dockerfile .
Tem de utilizar uma imagem principal suportada. Altere a imagem principal, substituindo a linha FROM pelo
seguinte código:
FROM mcr.microsoft.com/dotnet/framework/aspnet:4.7.2-windowsservercore-ltsc2019
No final do ficheiro, adicione a seguinte linha e guarde o ficheiro:
RUN ${source:-obj/Docker/publish/InstallFont.ps1}
Pode encontrar InstallFont.ps1 no projeto CustomFontSample . É um script simples que instala o tipo de letra.
Pode encontrar uma versão mais complexa do script no Centro de Scripts.
NOTE
Para testar o contentor do Windows localmente, certifique-se de que o Docker é iniciado na sua máquina local.
Publicar no Azure Container Registry

O Azure Container Registry pode armazenar as imagens de implementação de contentores. Pode configurar o
Serviço de Aplicações para utilizar imagens alojadas no Azure Container Registry.
Abrir o assistente de publicação
No Explorador de Soluções, clique com o botão direito do rato no projeto CustomFontSample e selecione
Publicar .
Criar registo e publicar
No assistente de publicação, selecione Registo de Contentores > Criar Novo Registo > deContentores
Azure****Publicar .
Iniciar sessão com a conta do Azure

Na caixa de diálogo Criar um Novo Registo de Contentor do Azure , selecione Adicionar uma conta e inicie
sessão na sua subscrição do Azure. Se já tem sessão iniciada, selecione a conta que contém a subscrição
pretendida na lista pendente.
Configurar o registo
Configure o novo registo de contentor com base nos valores sugeridos na tabela seguinte. Quando terminar, clique
em Criar .
Prefixo DNS Mantenha o nome do registo gerado

ou altere-o para outro nome exclusivo.
Grupo de Recursos Clique em Novo , escreva

myResourceGroup e clique em OK .
SKU Básico Escalões de preço
Localização do registo Europa ocidental

É aberta uma janela de terminal que mostra o progresso de implementação da imagem. Aguarde pela conclusão
da implementação.

Inicie sessão no portal do Azure em https://portal.azure.com.

A partir do menu esquerdo, selecione Criar uma > AplicaçãoWeb > de recursospara contentores .
Configurar o básico da aplicação
No separador Basics, configure as definições de acordo com a tabela seguinte e, em seguida, clique em Seguinte:
Docker .
Subscrição Certifique-se de que a subscrição

correta está selecionada.
Grupo de Recursos Selecione Criar novo, digitar o

meuGrupo de Recursos, e clicar OK .
Nome Escreva um nome exclusivo. O URL da aplicação Web é

http://<app-
name>.azurewebsites.net
, em que <app-name> é o nome da
aplicação.
Publicar Recipiente de estivador
Sistema Operativo Windows

Região Europa ocidental
Plano do Windows Selecione Criar novo, digitar

myAppSer vicePlan, e clicar OK .
O seu separador Basics deve ser assim:
Configurar o contentor do Windows

No separador Docker, configure o seu recipiente Windows personalizado como mostrado na tabela seguinte e
selecione Review + criar .
DEF IN IÇ Ã O VA LO R SUGERIDO
Origem da Imagem Registo de contentores azure

DEF IN IÇ Ã O VA LO R SUGERIDO
Registo Selecione o registo que criou anteriormente.
Imagem amostra de fonte personalizada
Tag mais recente
Criação de aplicação concluída

Clique em Criar e aguarde que o Azure crie os recursos necessários.
Navegar para a aplicação Web

Quando a operação do Azure estiver concluída, é apresentada uma caixa de notificação.
1. Clique em Ir para recurso .

2. Na página da aplicação, clique na ligação em URL .
É aberta uma página nova do browser na seguinte página:
Aguarde alguns minutos e tente novamente, até chegar à página de boas-vindas com o tipo de letra elegante de
que está à espera:
Parabéns! Migrou uma aplicação ASP.NET para o Serviço de Aplicações do Azure num contentor do Windows.
Ver os registos de arranque do contentor

O contentor do Windows poderá demorar algum tempo até ser carregado. Para ver o progresso, navegue para o
seguinte URL substituindo * <o nome da aplicação>* pelo nome da sua aplicação.
https://<app-name>.scm.azurewebsites.net/api/logstream
Os registos transmitidos têm o seguinte aspeto:
14/09/2018 23:16:19.889 INFO - Site: fonts-win-container - Creating container for image:

customfontsample20180914115836.azurecr.io/customfontsample:latest.
14/09/2018 23:16:19.928 INFO - Site: fonts-win-container - Create container for image:
customfontsample20180914115836.azurecr.io/customfontsample:latest succeeded. Container Id
329ecfedbe370f1d99857da7352a7633366b878607994ff1334461e44e6f5418
14/09/2018 23:17:23.405 INFO - Site: fonts-win-container - Start container succeeded. Container:
329ecfedbe370f1d99857da7352a7633366b878607994ff1334461e44e6f5418
14/09/2018 23:17:28.637 INFO - Site: fonts-win-container - Container ready
14/09/2018 23:17:28.637 INFO - Site: fonts-win-container - Configuring container
14/09/2018 23:18:03.823 INFO - Site: fonts-win-container - Container ready
14/09/2018 23:18:03.823 INFO - Site: fonts-win-container - Container start-up and configuration completed
successfully
Tutorial: Utilizar uma identidade gerida para proteger
a ligação da Base de Dados SQL do Azure a partir
do Serviço de Aplicações
O Serviço de Aplicações oferece um serviço de alojamento na Web altamente dimensionável e com correção
automática no Azure. Também oferece uma identidade gerida para a sua aplicação, que é uma solução chave na
mão para proteger o acesso à Base de Dados SQL do Azure e a outros serviços do Azure. As identidades geridas
no Serviço de Aplicações retiram a necessidade de ter segredos nas suas aplicações, como credenciais nas cadeias
de ligação, o que as torna mais seguras. Neste tutorial, você adicionará identidade gerida à aplicação web da
amostra que você construiu em um dos seguintes tutoriais:
Tutorial: Criar uma aplicação ASP.NET no Azure com a Base de Dados SQL
Tutorial: Construa uma app de base de dados core e SQL ASP.NET no Serviço de Aplicações Azure
Quando tiver terminado, a aplicação de exemplo irá ligar-se à Base de Dados SQL em segurança sem ser preciso o
nome de utilizador e a palavras-passe.
NOTE
Os passos abordados neste tutorial suportam as seguintes versões:
.QUADRO LÍQUIDO 4.7.2 e superior
.NET Core 2.2 e acima
O que vai aprender:

Ativar identidades geridas
Conceder acesso à Base de Dados SQL à identidade gerida
Configure Quadro de Entidade para usar autenticação Azure AD com Base de Dados SQL
Ligue-se à Base de Dados SQL do Estúdio Visual utilizando a autenticação Azure AD
NOTE
A autenticação Azure AD é diferente da autenticação integrada do Windows no diretório ativo no local (AD DS). A AD DS e a
AD Azure utilizam protocolos de autenticação completamente diferentes. Para mais informações, consulte a documentação
dos Serviços de Domínio da AD Azure.
Pré-requisitos
Este artigo continua onde deixou no Tutorial: Construa uma aplicação ASP.NET em Azure com Base de Dados SQL
ou Tutorial: Construa uma aplicação de base de dados core e SQL ASP.NET no Serviço de Aplicações Azure. Se
ainda não o fez, siga primeiro um dos dois tutoriais. Em alternativa, pode adaptar os passos para a sua própria
aplicação .NET com base de dados SQL.
Para desinserir a sua aplicação utilizando a Base de Dados SQL como parte de trás, certifique-se de que permitiu a
ligação ao cliente a partir do seu computador. Caso contrário, adicione o IP do cliente seguindo os passos das
regras de firewall IP de nível de servidor manage utilizando o portal Azure.

local.




no macOS.
Conceder acesso à base de dados ao utilizador da AD Azure

Primeiro, ativa a autenticação adigenante da Azure AD na Base de Dados SQL, atribuindo um utilizador de Anúncio
STA como administrador ative directory do servidor. Este utilizador é diferente da conta microsoft que usou para
se inscrever para a sua subscrição do Azure. Deve ser um utilizador que criou, importou, sincronizou ou convidou
para a AD Azure. Para obter mais informações sobre os utilizadores de Anúncios Azure autorizados, consulte as
funcionalidades e limitações da AD Azure na Base de Dados SQL.
Se o seu inquilino Azure AD ainda não tiver um utilizador, crie um seguindo os passos em Add ou elimine os
utilizadores usando o Diretório Ativo Azure.
Encontre o ID do objeto do utilizador DaD Azure utilizando o az ad user list e substitua <user-principal-name> .
O resultado é guardado para uma variável.
azureaduser=$(az ad user list --filter "userPrincipalName eq '<user-principal-name>'" --query [].objectId --

output tsv)
TIP
Para ver a lista de todos os nomes principais do utilizador em Azure AD, corra
az ad user list --query [].userPrincipalName .
Adicione este utilizador Azure AD como um administrador ative diretório utilizando

az sql server ad-admin create o comando na Cloud Shell. No comando seguinte, <server-name> substitua-o
pelo nome do servidor (sem o .database.windows.net sufixo).
az sql server ad-admin create --resource-group myResourceGroup --server-name <server-name> --display-name

ADMIN --object-id $azureaduser
Para obter mais informações sobre a adição de um administrador de Diretório Ativo, consulte Provision um
administrador de Diretório Ativo Azure para o seu servidor
Configurar o Visual Studio

Windows
O Visual Studio for Windows está integrado com a autenticação Azure AD. Para permitir o desenvolvimento e
depuração no Estúdio Visual, adicione o seu utilizador Azure AD no Estúdio Visual, selecionando definições de
conta de ficheiro > Account Settings sacar do menu e clique em Adicionar uma conta .
Para definir o utilizador Azure AD para Tools autenticação do serviço Azure, selecione > Tools Options do menu
e, em seguida, selecione A Seleção de Conta de Autenticação de Serviço Azure > Account Selection . Selecione o
utilizador Azure AD que adicionou e clique em OK .
Está agora pronto para desenvolver e depurar a sua aplicação com a Base de Dados SQL como parte de trás,
utilizando a autenticação Azure AD.
MacOS
O Visual Studio for Mac não está integrado com a autenticação Azure AD. No entanto, a biblioteca
Microsoft.Azure.Services.AppAuthentication que utilizará mais tarde pode utilizar tokens do Azure CLI. Para
permitir o desenvolvimento e depuração no Estúdio Visual, primeiro precisa de instalar o Azure CLI na sua
máquina local.
Assim que o Azure CLI estiver instalado na sua máquina local, inscreva-se no Azure CLI com o seguinte comando
utilizando o utilizador Azure AD:
az login --allow-no-subscriptions
Está agora pronto para desenvolver e depurar a sua aplicação com a Base de Dados SQL como parte de trás,
utilizando a autenticação Azure AD.
Modifique o seu projeto

Os passos que segue para o seu projeto dependem se é um projeto ASP.NET ou um projeto ASP.NET Core.
Modificar ASP.NET
Modificar ASP.NET Núcleo
Modificar ASP.NET
No Estúdio Visual, abra a Consola de Gestor de Pacotes e adicione o pacote NuGet
Microsoft.Azure.Services.Services.AppAuthentication:
Install-Package Microsoft.Azure.Services.AppAuthentication -Version 1.4.0
Em Web.config, trabalhando a partir da parte superior do ficheiro e efetuando as seguintes alterações:

In, <configSections> adicione a seguinte declaração de secção:
<section name="SqlAuthenticationProviders"
type="System.Data.SqlClient.SqlAuthenticationProviderConfigurationSection, System.Data,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
abaixo da etiqueta de </configSections> fecho, adicione o seguinte código XML para

<SqlAuthenticationProviders> .
<SqlAuthenticationProviders>
<providers>
<add name="Active Directory Interactive"
type="Microsoft.Azure.Services.AppAuthentication.SqlAppAuthenticationProvider,
Microsoft.Azure.Services.AppAuthentication" />
</providers>
</SqlAuthenticationProviders>
Encontre a cadeia de ligação chamada MyDbConnection e substitua o seu connectionString valor por
"server=tcp:<server-name>.database.windows.net;database=<db-name>;UID=AnyString;Authentication=Active
Directory Interactive"
. Substitua e com o nome do seu servidor e nome de base de <server-name> <db-name> dados.
NOTE
O SqlAuthenticationProvider que acabou de registar baseia-se na biblioteca appAuthentication que instalou anteriormente.
Por padrão, utiliza uma identidade atribuída ao sistema. Para alavancar uma identidade atribuída ao utilizador, terá de
fornecer uma configuração adicional. Consulte o suporte de cordas de ligação para a biblioteca AppAuthentication.
É tudo o que precisas para ligar à Base de Dados SQL. Ao depurar-se no Estúdio Visual, o seu código utiliza o
utilizador Azure AD configurado no set up Visual Studio. Mais tarde, irá configurar a Base de Dados SQL para
permitir a ligação a partir da identidade gerida da sua aplicação App Service.
Digite Ctrl+F5 para executar a aplicação novamente. A mesma aplicação CRUD no seu navegador está agora a
ligar-se diretamente à Base de Dados Azure SQL, utilizando a autenticação Azure AD. Esta configuração permite-
lhe executar migrações de base de dados do Estúdio Visual.
Modificar ASP.NET Núcleo
No Estúdio Visual, abra a Consola de Gestor de Pacotes e adicione o pacote NuGet
Microsoft.Azure.Services.Services.AppAuthentication:
Install-Package Microsoft.Azure.Services.AppAuthentication -Version 1.4.0
No tutorial de base de dados Core e SQL ASP.NET,a cadeia de ligação não é utilizada porque o ambiente de
desenvolvimento local utiliza um ficheiro de base de MyDbConnection dados Sqlite, e o ambiente de produção do
Azure usa uma cadeia de ligação do App Service. Com a autenticação de Diretório Ativo, pretende que ambos os
ambientes utilizem a mesma cadeia de ligação. Em aplicações.json, substitua o valor da cadeia de MyDbConnection
ligação com:
"Server=tcp:<server-name>.database.windows.net,1433;Database=<database-name>;"
Em seguida, fornece o contexto da base de dados 'Quadro de Entidades' com o token de acesso para a Base de
Dados SQL. Em Dados\MyDatabaseContext.cs, adicione o seguinte código dentro dos aparelhos encaracolados do
MyDatabaseContext (DbContextOptions<MyDatabaseContext> options) construtor vazio:
var conn = (Microsoft.Data.SqlClient.SqlConnection)Database.GetDbConnection();

conn.AccessToken = (new
Microsoft.Azure.Services.AppAuthentication.AzureServiceTokenProvider()).GetAccessTokenAsync("https://database.
windows.net/").Result;
NOTE
Este código de demonstração é sincronizado para a clareza e simplicidade.
É tudo o que precisas para ligar à Base de Dados SQL. Ao depurar-se no Estúdio Visual, o seu código utiliza o
utilizador Azure AD configurado no set up Visual Studio. Mais tarde, irá configurar a Base de Dados SQL para
permitir a ligação a partir da identidade gerida da sua aplicação App Service. A AzureServiceTokenProvider classe
cacheo o símbolo na memória e o recupera de Azure AD pouco antes de expirar. Não precisa de nenhum código
personalizado para refrescar o símbolo.
TIP
Se o utilizador da AD Azure configurado tiver acesso a vários inquilinos, ligue
GetAccessTokenAsync("https://database.windows.net/", tenantid) com o ID do inquilino pretendido para recuperar o
sinal de acesso adequado.
Digite Ctrl+F5 para executar a aplicação novamente. A mesma aplicação CRUD no seu navegador está agora a
ligar-se diretamente à Base de Dados Azure SQL, utilizando a autenticação Azure AD. Esta configuração permite-
lhe executar migrações de base de dados do Estúdio Visual.
Utilizar conectividade de identidade gerida

Em seguida, configura a sua aplicação App Service para se ligar à Base de Dados SQL com uma identidade gerida
atribuída pelo sistema.
NOTE
Embora as instruções nesta secção sejam para uma identidade atribuída ao sistema, uma identidade atribuída ao utilizador
pode facilmente ser utilizada. Para fazer isto. precisaria da alteração para atribuir a identidade atribuída ao
az webapp identity assign command utilizador pretendido. Em seguida, ao criar o utilizador SQL, certifique-se de usar o
nome do recurso de identidade atribuído ao utilizador em vez do nome do site.
Ativar identidade gerida na app

Para ativar uma identidade gerida na sua aplicação do Azure, utilize o comando az webapp identity assign no
Cloud Shell. No comando seguinte, substitua <app-name> .
az webapp identity assign --resource-group myResourceGroup --name <app-name>
Aqui está um exemplo da saída:

{
"additionalProperties": {},
"principalId": "21dfa71c-9e6f-4d17-9e90-1d28801c9735",
"tenantId": "72f988bf-86f1-41af-91ab-2d7cd011db47",
"type": "SystemAssigned"
}
Conceder permissões à identidade gerida
NOTE
Se quiser, pode adicionar a identidade a um grupo Azure AD,em seguida, conceder acesso à Base de Dados SQL ao grupo
Azure AD em vez da identidade. Por exemplo, os seguintes comandos adicionam a identidade gerida do passo anterior a um
novo grupo chamado myAzureSQLDBAccessGroup:
groupid=$(az ad group create --display-name myAzureSQLDBAccessGroup --mail-nickname

myAzureSQLDBAccessGroup --query objectId --output tsv)
msiobjectid=$(az webapp identity show --resource-group myResourceGroup --name <app-name> --query
principalId --output tsv)
az ad group member add --group $groupid --member-id $msiobjectid
az ad group member list -g $groupid
No Cloud Shell, utilize o comando SQLCMD para iniciar sessão na Base de Dados SQL. <server-name> Substitua-o
pelo nome do servidor, com o nome de base de <db-name> dados que a sua aplicação utiliza e com as credenciais
do utilizador do <aad-user-name> <aad-password> Azure AD.
sqlcmd -S <server-name>.database.windows.net -d <db-name> -U <aad-user-name> -P "<aad-password>" -G -l 30
No pedido SQL para a base de dados que deseja, execute os seguintes comandos para conceder as permissões de
que a sua aplicação necessita. Por exemplo,
CREATE USER [<identity-name>] FROM EXTERNAL PROVIDER;

ALTER ROLE db_datareader ADD MEMBER [<identity-name>];
ALTER ROLE db_datawriter ADD MEMBER [<identity-name>];
ALTER ROLE db_ddladmin ADD MEMBER [<identity-name>];
GO
<identity-name> é o nome da identidade gerida em Azure AD. Se a identidade for atribuída ao sistema, o nome é
sempre o mesmo que o nome da sua aplicação App Service. Para conceder permissões a um grupo Azure AD,
utilize o nome de exibição do grupo (por exemplo, myAzureSQLDBAccessGroup).
Escreva EXIT para regressar à linha de comandos do Cloud Shell.
NOTE
Os serviços de back-end de identidades geridas também mantêm uma cache simbólica que atualiza o símbolo para um
recurso-alvo apenas quando expira. Se cometer um erro ao configurar as suas permissões de Base de Dados SQL e tentar
modificar as permissões depois de tentar obter um sinal com a sua aplicação, não obtém um novo símbolo com as
permissões atualizadas até que o token em cache expire.
Modificar a cadeia de ligação

Lembre-se que as mesmas alterações que fez em Web.config ou appsettings.json trabalha com a identidade
gerida, pelo que a única coisa a fazer é remover a cadeia de ligação existente no App Service, que o Visual Studio
criou implementando a sua aplicação pela primeira vez. Utilize o seguinte comando, mas <app-name> substitua-o
pelo nome da sua aplicação.
az webapp config connection-string delete --resource-group myResourceGroup --name <app-name> --setting-names

MyDbConnection
Publicar as alterações
Agora, só falta publicar as alterações no Azure.
Se veio do Tutorial: Construa uma aplicação ASP.NET em Azure com base de dados SQL, publique as
suas alterações no Estúdio Visual. No Explorador de Soluções , clique com o botão direito do rato no projeto
DotNetAppSqlDb e selecione Publicar .
Na página de publicação, clique em Publicar .

Se veio do Tutorial: Construa uma aplicação de base de dados Core e SQL ASP.NET no Ser viço de
Aplicações Azure, publique as suas alterações utilizando git, com os seguintes comandos:
git commit -am "configure managed identity"

Quando a página Web nova mostrar a lista de tarefas, significa que a aplicação se está a ligar à base de dados com
a identidade gerida.
Agora, deverá conseguir editar a lista de tarefas como antes.
Limpar recursos
Próximos passos
O que aprendeu:
Ativar identidades geridas
Conceder acesso à Base de Dados SQL à identidade gerida
Configure Quadro de Entidade para usar autenticação Azure AD com Base de Dados SQL
Ligue-se à Base de Dados SQL do Estúdio Visual utilizando a autenticação Azure AD
Avance para o próximo tutorial para saber como mapear um nome DNS personalizado para a aplicação Web.
Tutorial: Alojar uma API RESTful com CORS no
Serviço de Aplicações do Azure
correção automática. Além disso, o Serviço de Aplicações tem suporte incorporado para Partilha de Recursos de
Várias Origens (CORS) para APIs RESTful. Este tutorial mostra como implementar uma aplicação API ASP.NET Core
no Serviço de Aplicações com suporte para CORS. A aplicação é configurada com ferramentas de linha de
comandos e implementada na aplicação através do Git.
Criar recursos do Serviço de Aplicações com a CLI do Azure
Implementar uma API RESTful no Azure com o Git
Ativar o suporte para CORS no Serviço de Aplicações
Pode seguir os passos neste tutorial em macOS, Linux e Windows.
Pré-requisitos
Instalar o Git

Neste passo, vai configurar o projeto ASP.NET Core local. O Serviço de Aplicações suporta o mesmo fluxo de
trabalho para APIs escritas noutras linguagens.
git clone https://github.com/Azure-Samples/dotnet-core-api
Este repositório contém uma aplicação que é criada com base no tutorial ASP.NET Core Web API help pages using
Swagger (Páginas de ajuda da API Web ASP.NET Core mediante a utilização do Swagger). Utiliza um gerador do
Swagger para servir a IU do Swagger e o ponto final JSON do Swagger.
Execute os seguintes comandos para instalar os pacotes necessários, executar migrações de base de dados e iniciar
a aplicação.
cd dotnet-core-api
dotnet restore
dotnet run
Navegue para http://localhost:5000/swagger num browser para reproduzir com a IU do Swagger.
Navegue para http://localhost:5000/api/todo e veja uma lista de itens JSON ToDo

Navegue para http://localhost:5000 e experimente a aplicação de browser. Mais tarde, vai apontar a aplicação de
browser para uma API remota no Serviço de Aplicações para testar a funcionalidade CORS. O código para a
aplicação de browser está no diretório wwwroot do repositório.
Para parar o ASP.NET Core em qualquer altura, prima Ctrl+C no terminal.

local.




no macOS.

Neste passo, vai implementar a aplicação .NET Core ligada à Base de Dados SQL no Serviço de Aplicações.
Configurar a implementação do git local
seguinte exemplo:
{
"kind": "app",
}

nome de aplicação globalmente exclusivo (os carateres válidos são a-z , 0-9 e - ).
az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name <app-name> --deployment-

local-git
name>.git'
{
"clientCertExclusionPaths": null,
"containerSize": 0,
"enabled": true,
}
NOTE
dele mais tarde.

web.
exemplo seguinte:
Enumerating objects: 83, done.
Counting objects: 100% (83/83), done.
Delta compression using up to 8 threads
Writing objects: 100% (83/83), 22.15 KiB | 3.69 MiB/s, done.
remote: Preparing deployment for commit id '509236e13d'.
remote: Project file path: .\TodoApi.csproj
remote: Generating deployment script for ASP.NET MSBuild16 App
remote: Generated deployment script files
remote: Handling ASP.NET Core Web Application deployment with MSBuild16.
remote: .
remote: .
remote: .
remote: Triggering recycle (preview mode disabled).
To https://<app_name>.scm.azurewebsites.net/<app_name>.git

Navegue para http://<app_name>.azurewebsites.net/swagger num browser experimente a IU do Swagger.
Navegue para http://<app_name>.azurewebsites.net/swagger/v1/swagger.json para ver o swagger.json da API
implementada.
Navegue para http://<app_name>.azurewebsites.net/api/todo para ver a API implementada em funcionamento.
Adicionar a funcionalidade CORS

Em seguida, ative o suporte de CORS no Serviço de Aplicações para a sua API.
Testar CORS na aplicação de exemplo
No seu repositório local, abra wwwroot/index.html.
Na Linha 51, defina a variável apiEndpointcomo o URL da API implementada (
http://<app_name>.azurewebsites.net ). Substitua o _ <nome de aplicações>_ pelo nome da sua aplicação no
Serviço de Aplicações.
Na janela de terminal local, execute novamente a aplicação de exemplo.
dotnet run
Navegue para a aplicação de browser em http://localhost:5000 . Abra a janela de ferramentas de

desenvolvimento no seu navegador (no Ctrl + Shift + i Chrome para Windows) e inspecione o separador
Consola. Agora deve ver a No 'Access-Control-Allow-Origin' header is present on the requested resource
mensagem de erro.
Devido à falta de correspondência de domínio entre a aplicação de browser ( http://localhost:5000 ) e o recurso
remoto ( http://<app_name>.azurewebsites.net ) e o facto de a sua API no Serviço de Aplicações não estar a enviar o
cabeçalho Access-Control-Allow-Origin , o browser impediu o carregamento de conteúdos de vários domínios na
sua aplicação de browser.
Na produção, a aplicação de browser teria um URL público em vez do URL de localhost, mas a forma de ativar o
CORS para um URL de localhost é igual à dos URLs públicos.
Ativar o CORS
Na Cloud Shell, ative o CORS no URL az webapp cors add do seu cliente utilizando o comando. Substitua o _
<nome da aplicação>_ espaço reservado.
az webapp cors add --resource-group myResourceGroup --name <app-name> --allowed-origins

'http://localhost:5000'
Pode definir mais de um URL do cliente em properties.cors.allowedOrigins ( "['URL1','URL2',...]" ). Também

pode ativar todos os URLs do cliente com "['*']" .
NOTE
Se a sua aplicação necessitar de credenciais como cookies ou fichas ACCESS-CONTROL-ALLOW-CREDENTIALS de autenticação
para ser enviada, o navegador poderá necessitar do cabeçalho na resposta. Para ativar isto no
properties.cors.supportCredentials Serviço true de Aplicações, coloque-o no seu config CORS. Isto não pode
allowedOrigins ser '*' ativado quando inclui .
Testar o CORS novamente

Ative a aplicação de browser em http://localhost:5000 . A mensagem de erro na janela Consola deixa de estar
visível e pode ver os dados da API implementada e interagir com os mesmos. A API remota suporta agora CORS
na sua aplicação de browser em execução no local.
Parabéns! Está a executar uma API no Serviço de Aplicações do Azure com suporte para CORS.
CORS do Serviço de Aplicações vs. o seu CORS

Pode utilizar os seus próprios utilitários CORS em vez do CORS do Serviço de Aplicações para uma maior
flexibilidade. Por exemplo, poderá querer especificar diferentes origens permitidas para rotas ou métodos
diferentes. Uma vez que o CORS do Serviço de Aplicações lhe permite especificar um conjunto de origens aceites
para todas as rotas e métodos da API, poderá pretender utilizar o seu próprio código de CORS. Veja como é que o
ASP.NET Core o faz em Enabling Cross-Origin Requests (CORS) (Ativar Pedidos de Várias Origens [CORS]).
NOTE
Não tente utilizar o CORS do Serviço de Aplicações o seu próprio código CORS em conjunto. Quando utilizados em conjunto,
o CORS do Serviço de Aplicações tem precedência e o seu código não tem qualquer efeito.
Limpar recursos
Passos seguintes
O que aprendeu:
Criar recursos do Serviço de Aplicações com a CLI do Azure
Implementar uma API RESTful no Azure com o Git
Ativar o suporte para CORS no Serviço de Aplicações
Avançar para o próximo tutorial para saber como autenticar e autorizar utilizadores.
Tutorial: Autenticar e autorizar utilizadores ponto a ponto
Tutorial: Mapeie um nome dNS personalizado
existente para o Serviço de Aplicações Azure
correção automática. Este tutorial mostra-lhe como mapear um nome DNS personalizado existente para o
Serviço de Aplicações Azure.

Mapear um subdomínio (por exemplo, www.contoso.com ) através da utilização de um registo CNAME
Mapear um domínio raiz (por exemplo, contoso.com ) através da utilização de um registo A
Mapear um domínio com carateres universais (por exemplo, *.contoso.com ) através da utilização de um
registo CNAME
Redirecionar o URL predefinido para um diretório personalizado
Automatizar o mapeamento de domínios com scripts
Pré-requisitos
Crie uma aplicação do Serviço de Aplicações ou utilize uma aplicação que tenha criado para outro
tutorial.
Compre um nome de domínio e confirme que tem acesso ao registo DNS do seu fornecedor de
domínio (como a GoDaddy).
Por exemplo, para adicionar entradas DNS para contoso.com e www.contoso.com , tem de ter poder
configurar as definições de DNS para o domínio de raiz contoso.com .
NOTE
Se não tiver um nome de domínio já existente, considere comprar um domínio através do portal do Azure.
Preparar a aplicação
Para mapear um nome DNS personalizado para uma aplicação web, o plano de Serviço de Aplicações da
aplicação web deve ser um nível pago (Shared , Basic , Standard , Premium ou Consumption for Azure
Functions). Neste passo, vai confirmar que a aplicação do Serviço de Aplicações está no escalão de preço
suportado.
NOTE
Os planos de hospedagem gratuitos e partilhados (pré-visualização) são os planos de hospedagem de níveis base que
funcionam nas mesmas máquinas virtuais Azure que outras aplicações do App Service. Algumas aplicações podem
pertencer a outros clientes. Estas camadas destinam-se a ser utilizadas apenas para efeitos de desenvolvimento e teste.

Abra ao portal do Azure e inicie sessão com a sua conta do Azure.
Selecione a aplicação no portal Azure
Procure e selecione Serviços de Aplicações .

Será apresentada a página de gestão da aplicação do Serviço de Aplicações.
Verificar o escalão de preço
No painel de navegação esquerdo da página da aplicação, desloque-se para a secção Definições e selecione
Aumentar ver ticalmente (plano do Ser viço de Aplicações) .
O escalão atual da aplicação é realçado com um limite azul. Confirme que a aplicação não está no escalão F1 .
O DNS personalizado não é suportado no escalão F1 .
Se o plano do Serviço de Aplicações não estiver no escalão F1 , feche a página Aumentar ver ticalmente e
avance para Mapear um registo CNAME.
Aumentar verticalmente o plano do Serviço de Aplicações
Selecione qualquer uma das camadas não gratuitas (D1 , B1 , B2 , B3 ou qualquer camada na categoria
Produção ). Para obter opções adicionais, clique em Ver opções adicionais .
Clique em Aplicar .
Quando vir a notificação seguinte, significa que a operação de dimensionamento está completa.
Obter ID de verificação de domínio

Para adicionar um domínio personalizado à sua aplicação, precisa de verificar a sua propriedade do domínio
adicionando um ID de verificação como um registo TXT com o seu fornecedor de domínio. Na navegação à
esquerda da sua página de aplicações, clique em Resource explorer em Ferramentas de Desenvolvimento e,
em seguida, clique em Go .
Na visão json das propriedades da sua customDomainVerificationId aplicação, procure , e copie o seu valor
dentro das cotações duplas. Precisa desta identificação de verificação para o próximo passo.
Mapear o seu domínio

Para mapear um nome DNS personalizado para o Serviço de Aplicações, pode utilizar tanto um registo
CNAME , como um registo A . Siga os passos correspondentes:
Mapear um registo CNAME
Mapear um registo A
Mapear um domínio de caráter universal (com um registo CNAME)
NOTE
Deve utilizar os registos CNAME para todos os nomes DNS personalizados, exceto os domínios de raiz (por exemplo,
contoso.com ). Para os domínios de raiz, utilize registos A.
Mapear um registo CNAME

No exemplo do tutorial, vai adicionar um registo CNAME ao subdomínio www (por exemplo, www.contoso.com ).
Aceder a registos DNS com o fornecedor de domínios
NOTE
Pode utilizar o Azure DNS para configurar um nome DNS personalizado para o Serviço de Aplicações Azure. Para obter
mais informações, veja Utilizar o DNS do Azure para oferecer definições de domínio personalizado para um serviço do
Azure.
Inicie sessão no site do fornecedor do seu domínio.

Localize a página para gerir os registos DNS. Cada fornecedor de domínio tem a sua própria interface de
registos DNS, por isso, consulte a documentação do fornecedor. Procure áreas do site com os nomes Nome
de Domínio , DNS ou Gestão de Ser vidor de Nomes .
Em muitos casos, pode encontrar a página de registos DNS ao procurar uma ligação como Os meus
domínios nas informações da sua conta. Aceda a essa página e procure uma ligação que tenha um nome
parecido com Ficheiro de zona , Registos DNS ou Configuração avançada .
A captura de ecrã seguinte mostra um exemplo de uma página de registos DNS:
Na captura de ecrã de exemplo, selecione adicionar para criar um registo. Alguns fornecedores têm ligações
diferentes para adicionar diferentes tipos de registos. Novamente, consulte a documentação do fornecedor.
NOTE
Para alguns fornecedores, como a GoDaddy, as alterações aos registos DNS só entram em vigor quando selecionar uma
ligação Guardar Alterações separada.
Criar o registo CNAME

Mapeie um subdomínio para o <app_name>.azurewebsites.net nome <app_name> de domínio padrão da
aplicação (onde está o nome da sua aplicação). Para criar um mapeamento www CNAME para o subdomínio,
crie dois registos:
T IP O DE REGISTO A N F IT RIÃ O VA LO R C O M EN TÁ RIO S
CNAME www <app_name>.azurewebsites.netO domínio mapeamento

em si.
TXT asuid.www A identificação de O Serviço de

verificação que obteve mais asuid.<subdomain>
cedo Aplicações acede ao registo
TXT para verificar a sua
propriedade do domínio
personalizado.
Depois de adicionar os registos CNAME e TXT, a página de registos DNS parece ser o seguinte exemplo:
Ativar o mapeamento de registos CNAME no Azure

No painel de navegação esquerdo da página da aplicação no portal do Azure, selecione Domínios
personalizados .
N página Domínios personalizados da aplicação, adicione o nome DNS personalizado completamente

qualificado ( www.contoso.com ) à lista.
Selecione o + ícone ao lado de Adicionar domínio personalizado .
Escreva o nome de domínio completamente qualificado ao qual adicionou um registo CNAME, como
www.contoso.com .
Selecione Validar .
A página de domínio personalizado Adicionar é mostrada.
Certifique-se de que o tipo de registo do Nome anfitrião está definido para CNAME.(www example.com
ou qualquer subdomínio) .
Selecione Adicionar domínio personalizado .
Pode levar algum tempo para que o novo domínio personalizado seja refletido na página de domínios
Personalizados da aplicação. Experimente atualizar o browser para atualizar os dados.
NOTE
Uma etiqueta Não Segura para o seu domínio personalizado significa que ainda não está ligada a um certificado
TLS/SSL, e qualquer pedido HTTPS de um navegador para o seu domínio personalizado receberá e erro ou aviso,
dependendo do navegador. Para adicionar uma ligação TLS, consulte Proteja um nome DNS personalizado com uma
ligação TLS/SSL no Serviço de Aplicações Azure.
Se tiver perdido um passo ou escrito algo mal em algum momento acima, verá um erro de verificação na
parte inferior da página.
Mapear um registo A
No exemplo do tutorial, vai adicionar um registo A ao domínio de raiz (por exemplo, contoso.com ).
Copiar o endereço IP da aplicação
Para mapear um registo A, precisa do endereço IP externo da aplicação. Pode encontrar este endereço IP na
página Domínios personalizados da aplicação, no portal do Azure.
personalizados .
Na página Domínios personalizados , copie o endereço IP da aplicação.

NOTE
Azure.

NOTE
Criar um registo A
Para mapear um registo A para uma aplicação, geralmente para o domínio raiz, criar dois registos:
T IP O DE REGISTO A N F IT RIÃ O VA LO R C O M EN TÁ RIO S
A @ Endereço IP de Copiar o O próprio mapeamento @

endereço IP da aplicação de domínio (normalmente
representa o domínio raiz).
TXT asuid A identificação de O Serviço de

verificação que obteve mais asuid.<subdomain>
cedo Aplicações acede ao registo
TXT para verificar a sua
propriedade do domínio
personalizado. Para o
domínio asuid raiz, utilize.
NOTE
Para adicionar um subdomínio (como) www.contoso.com utilizando um disco A em vez de um registo
CNAMErecomendado, o seu registo A e o registo TXT devem parecer a seguinte tabela:
T I P O D E R E G I S TO ANF I TR I ÃO VA L O R
A www Endereço IP de Copiar o endereço IP

da aplicação
TXT asuid.www <app_name>.azurewebsites.net
Quando os registos estiverem adicionados, a página de registos DNS terá um aspeto semelhante ao seguinte
exemplo:
Ativar o mapeamento de registos A na aplicação

Novamente na página Domínios personalizados da aplicação, no portal do Azure, adicione o nome DNS
personalizado completamente qualificado (por exemplo, contoso.com ) à lista.
Escreva o nome de domínio completamente qualificado para o qual configurou o registo A, como contoso.com
.
Selecione Validar .
A página de domínio personalizado Adicionar é mostrada.
Confirme que o Tipo de registo de nome de anfitrião está definido como Registo A
( www.example.com ) .
NOTE
Uma etiqueta Não Segura para o seu domínio personalizado significa que ainda não está ligada a um certificado
Se tiver perdido um passo ou escrito algo mal em algum momento acima, verá um erro de verificação na
parte inferior da página.
Mapear um domínio com caráteres universais

No exemplo do tutorial, vai mapear um nome DNS com carateres universais (por exemplo, *.contoso.com )
para a aplicação do Serviço de Aplicações ao adicionar um registo CNAME.
NOTE
Azure.

NOTE
Criar o registo CNAME

Adicione um registo CNAME para mapear um nome wildcard <app_name>.azurewebsites.net para o nome de
domínio padrão da aplicação ().
No domínio de exemplo *.contoso.com , o registo CNAME vai mapear o nome * para
<app_name>.azurewebsites.net .
Quando o CNAME estiver adicionado, a página de registos DNS terá um aspeto semelhante ao seguinte
exemplo:
Ativar o mapeamento de registos CNAME na aplicação
Agora, pode adicionar qualquer subdomínio que corresponda ao nome com caráteres universais à aplicação
(por exemplo, sub1.contoso.com e sub2.contoso.com correspondem a *.contoso.com ).
personalizados .
Escreva um nome de domínio completamente qualificado que corresponda ao domínio de caráter universal
(por exemplo, sub1.contoso.com ) e, em seguida, selecione Validar .
O botão de domínio personalizado Adicionar é ativado.
Certifique-se de que o tipo de registo do Nome anfitrião está definido para o registo CNAME (www
example.com.ou qualquer subdomínio) .
Selecione novamente o + ícone para adicionar outro domínio personalizado que corresponda ao domínio
wildcard. Por exemplo, adicione sub2.contoso.com .
NOTE
Uma etiqueta Note Secure para o seu domínio personalizado significa que ainda não está ligada a um certificado
Testar no browser
Navegue para o nome ou nomes DNS que configurou anteriormente (por exemplo, contoso.com ,
www.contoso.com , sub1.contoso.com e sub2.contoso.com ).
Resolver 404 "Não Encontrados"

Se receber o erro de HTTP 404 (Não Encontrado) ao navegar para o URL do seu domínio personalizado, utilize
WhatsmyDNS.net para confirmar que o domínio é resolvido para o endereço IP da sua aplicação. Se não for,
essa situação poderá dever-se a um dos motivos seguintes:
Falta um registo A e/ou um registo CNAME ao domínio personalizado configurado.
O cliente do browser colocou em cache o endereço IP antigo do seu domínio. Limpe a cache e volte a testar
a resolução de DNS. Num computador Windows, limpe a cache com ipconfig /flushdns .
Migrar um domínio ativo
Para migrar um site em direto e o respetivo nome de domínio DNS para o Serviço de Aplicações, consulte
Migrar um nome DNS ativo para o Serviço de Aplicações do Azure.
Redirecionar para um diretório personalizado

Por predefinição, o Serviço de Aplicações direciona os pedidos Web para o diretório de raiz do código da sua
aplicação. No entanto, determinadas estruturas da Web não são iniciadas no diretório de raiz. Por exemplo, o
Laravel é iniciado no subdiretório public . Para continuar com o exemplo de DNS contoso.com , essa aplicação
seria acessível em http://contoso.com/public , mas o que realmente quereria era direcionar
http://contoso.com para o diretório public . Este passo não envolve a resolução de DNS, mas sim a
personalização do diretório virtual.
Para tal, selecione Definições da Aplicação no painel de navegação esquerdo da página da aplicação Web.
Na parte inferior da página, o diretório de raiz virtual / aponta para site\wwwroot por predefinição, que é o
diretório de raiz do código da aplicação. Altere-o para apontar para site\wwwroot\public , por exemplo, e
guarde as alterações.
Uma vez concluída a operação, a sua aplicação deve devolver http://contoso.com a página certa no caminho
raiz (por exemplo, ).
Automatizar com scripts

Pode automatizar a gestão de domínios personalizados com scripts através da CLI do Azure ou do Azure
PowerShell.
CLI do Azure
O comando seguinte adiciona um nome DNS personalizado configurado a uma aplicação do Serviço de
Aplicações.
az webapp config hostname add \

--webapp-name <app_name> \
--resource-group <resource_group_name> \
--hostname <fully_qualified_domain_name>
Para obter mais informações, veja Map a custom domain to a web app (Mapear um domínio personalizado a
uma aplicação Web).
Azure PowerShell
NOTE
Este artigo foi atualizado para utilizar o novo módulo AZ do Azure PowerShell. Pode continuar a utilizar o módulo
AzureRM, que continuará a receber correções de erros até, pelo menos, dezembro de 2020. Para obter mais informações
sobre o novo módulo Az e a compatibilidade do AzureRM, veja Apresentação do novo módulo Az do Azure PowerShell.
Para obter instruções de instalação do módulo Az, veja Instalar o Azure PowerShell.
O comando seguinte adiciona um nome DNS personalizado configurado a uma aplicação do Serviço de
Aplicações.
Set-AzWebApp `
-Name <app_name> `
-ResourceGroupName <resource_group_name> `
-HostNames @("<fully_qualified_domain_name>","<app_name>.azurewebsites.net")
Para obter mais informações, veja Assign a custom domain to a web app (Atribuir um domínio personalizado a
uma aplicação Web).
Passos seguintes
Mapear um subdomínio com um registo CNAME
Mapear um domínio de raiz com um registo A
Mapear um domínio de caráter universal com um registo CNAME
Redirecionar o URL predefinido para um diretório personalizado
Automatizar o mapeamento de domínios com scripts
Avance para o próximo tutorial para aprender a ligar um certificado Personalizado TLS/SSL a uma aplicação
web.
Proteja um nome DNS personalizado com uma ligação TLS/SSL no Serviço de Aplicações Azure
Proteja um nome DNS personalizado com uma
ligação TLS/SSL no Serviço de Aplicações Azure
Este artigo mostra-lhe como proteger o domínio personalizado na sua app de serviço de aplicação ou
aplicação de função do App Service, criando um certificado vinculativo. Quando terminar, pode aceder à sua
aplicação https:// App Service no ponto final para https://www.contoso.com o seu nome DNS personalizado
(por exemplo, ).
A segurança de um domínio personalizado com um certificado envolve dois passos:

Adicione um certificado privado ao Serviço de Aplicações que satisfaça todos os requisitos de certificado
privado.
Crie uma ligação TLS ao domínio personalizado correspondente. Este segundo passo é coberto por este
artigo.
Atualizar o escalão de preço da sua aplicação
Proteja um domínio personalizado com um certificado
Impor HTTPS
Impor TLS 1.1/1.2
Automatizar a gestão de TLS com scripts
Pré-requisitos
Para seguir este guia:
Criar uma aplicação do Serviço de Aplicações
Mapeie um nome de domínio para a sua app ou compre e configure-o em Azure
Adicione um certificado privado à sua aplicação
NOTE
A maneira mais fácil de adicionar um certificado privado é criar um Certificado Gerido por Serviço de Aplicações gratuito
(Pré-visualização).
Preparar a sua aplicação Web
Para criar encadernações de segurança personalizadas ou ativar certificados de cliente para a sua app App
Service, o seu plano de Serviço de Aplicações deve estar no nível Básico , Standard , Premium ou Isolado.
Neste passo, vai confirmar que a aplicação Web está no escalão de preço suportado.
Abra o portal Azure.
Navegue até à sua aplicação Web

Aterrou na página de gestão da sua aplicação web.
No painel de navegação esquerdo da página da aplicação Web, desloque-se para a secção Definições e
selecione Aumentar ver ticalmente (plano do Ser viço de Aplicações) .
Confirme que a aplicação Web não está no escalão F1 ou D1 . O escalão atual da aplicação é realçado com uma
caixa azul-escura.
O SSL personalizado não é suportado nos escalões F1 ou D1 . Se precisar de aumentar verticalmente, siga os
passos na secção seguinte. Caso contrário, feche a página Scale up e salte a secção de plano seletiva para
cima.
Aumentar verticalmente o seu plano do Serviço de Aplicações
Selecione qualquer uma das camadas não gratuitas (B1 , B2 , B3 ou qualquer camada na categoria Produção ).
Para obter opções adicionais, clique em Ver opções adicionais .
Clique em Aplicar .
Proteja um domínio personalizado

Faça os seguintes passos:
No portal Azure, a partir do menu esquerdo, selecione o**<nome da aplicação ** App Ser vices > >.
A partir da navegação à esquerda da sua aplicação, inicie o diálogo de ligação TLS/SSL por:
Selecionar domínios personalizados > Adicione a ligação
Selecionando as > definições TLS/SSL****Adicione a ligação TLS/SSL
No Domínio Personalizado, selecione o domínio personalizado para o que pretende adicionar uma ligação.
Se a sua aplicação já tiver um certificado para o domínio personalizado selecionado, vá diretamente à Create
Binding. Caso contrário, continua.
Adicione um certificado para domínio personalizado
Se a sua aplicação não tiver certificado para o domínio personalizado selecionado, então tem duas opções:
Carregar Cer tificado PFX - Siga o fluxo de trabalho no Upload de um certificado privadoe, em seguida,
selecione esta opção aqui.
Certificado de serviço de aplicações de impor tação - Siga o fluxo de trabalho na Importação de um
certificado de Serviço de Aplicaçõese, em seguida, selecione esta opção aqui.
NOTE
Também pode criar um certificado gratuito (Pré-visualização) ou importar um certificado de cofre de chave,mas deve
fazê-lo separadamente e depois voltar ao diálogo de ligação TLS/SSL.
Criar encadernação
Utilize a tabela seguinte para o ajudar a configurar a ligação TLS no diálogo de ligação TLS/SSL e, em
seguida, clique em Adicionar Encadernação .
DEF IN IÇ Ã O DESC RIÇ Ã O
Domínio personalizado O nome de domínio para adicionar a ligação TLS/SSL para.
Impressão digital de certificado privado O certificado para ligar.

Tipo TLS/SSL Podem ser adicionadas ligações SNI SSL - Múltiplas

ligações SNI SSL. Esta opção permite que vários
certificados TLS/SSL garantam vários domínios no
mesmo endereço IP. A maioria dos navegadores
modernos (incluindo Internet Explorer, Chrome,
Firefox e Opera) suportam SNI (para mais
informações, consulte Indicação de Nomedo
Servidor).
IP SSL - Só pode ser adicionada uma ligação IP SSL.
Esta opção permite apenas um certificado TLS/SSL
para garantir um endereço IP público dedicado.
Depois de configurar a ligação, siga os passos nos
registos de Remap para IP SSL.
Ip SSL é suportado apenas em nível Standard ou
superior.
Uma vez concluída a operação, o estado TLS/SSL do domínio personalizado é alterado para Secure .
NOTE
Um estado seguro nos domínios Personalizados significa que está protegido com um certificado, mas o Serviço de
Aplicações não verifica se o certificado é auto-assinado ou expirado, por exemplo, o que também pode fazer com que os
navegadores mostrem um erro ou aviso.
Remap registos para IP SSL

Se não utilizar o IP SSL na sua aplicação, salte para o Teste HTTPS para o seu domínio personalizado.
Há duas alterações que precisa de fazer, potencialmente:
Por padrão, a sua aplicação utiliza um endereço IP público partilhado. Quando liga um certificado com
IP SSL, o App Service cria um novo endereço IP dedicado para a sua aplicação. Se mapeou um registo A
para a sua aplicação, atualize o seu registo de domínio com este novo endereço IP dedicado.
A página de domínio Personalizado da sua aplicação é atualizada com o novo endereço IP dedicado.
Copie este endereço IP e remapeie o registo A para este endereço IP novo.
Se tiver uma ligação SNI <app-name>.azurewebsites.net SSL, remape qualquer mapeamento CNAME
para sni.<app-name>.azurewebsites.net apontar (adicione o sni prefixo).
Tester HTTPS
Em vários navegadores, https://<your.custom.domain> navegue para verificar se serve a sua aplicação.
O seu código de aplicação pode inspecionar o protocolo através do cabeçalho "x-appservice-proto". O
cabeçalho terá http um https valor de ou .
NOTE
Se a sua aplicação lhe der erros de validação de certificados, provavelmente está a usar um certificado auto-assinado.
Se não for esse o caso, poderá ter deixou de fora certificados intermédios quando exportou o certificado para o ficheiro
PFX.
Prevenir alterações ip
O seu endereço IP de entrada pode alterar-se quando elimina uma ligação, mesmo que essa ligação seja IP
SSL. Isto é especialmente importante quando renova um certificado que já está numa ligação IP SSL. Para
evitar uma alteração de endereço IP da sua aplicação, siga estes passos por ordem:
1. Carregar o novo certificado.
2. Vincular o novo certificado com o domínio personalizado que pretende sem eliminar os antigo. Esta ação
substitui o enlace em vez de remover o antigo.
3. Eliminar o certificado antigo.
Impor HTTPS
Por padrão, qualquer pessoa ainda pode aceder à sua aplicação usando HTTP. Pode redirecionar todos os
pedidos HTTP para a porta HTTPS.
Na página da sua aplicação, na navegação à esquerda, selecione as definições SSL . Em seguida, em HTTPS
Apenas , selecione Ativado .
Quando a operação for concluída, navegue para um dos URLs HTTP que apontam para a sua aplicação. Por
exemplo:
http://<app_name>.azurewebsites.net
http://contoso.com
http://www.contoso.com
Impor versões do TLS

A aplicação permite o TLS 1.2 por predefinição, o que é o nível do TLS recomendado pelas normas do setor,
como PCI DSS. Para impor versões do TLS diferentes, siga estes passos:
Na página da sua aplicação, na navegação à esquerda, selecione as definições SSL . Em seguida, na versão
do TLS , selecione a versão mínima do TLS que pretende. Esta definição controla apenas as chamadas de
entrada.
Quando a operação for concluída, a sua aplicação rejeita todas as ligações com versões do TLS inferiores.
Manuseie a rescisão de TLS

No Serviço de Aplicações, a rescisão de TLS ocorre nos equilibradores de carga da rede, pelo que todos os
pedidos HTTPS chegam à sua aplicação como pedidos HTTP não encriptados. Se a lógica da sua aplicação
necessitar de verificar se X-Forwarded-Proto os pedidos do utilizador estão encriptados ou não, inspecione o
cabeçalho.
Guias de configuração específicos do idioma, como o guia de configuração Linux Node.js, mostram-lhe como
detetar uma sessão HTTPS no seu código de aplicação.

CLI do Azure
#!/bin/bash
fqdn=<replace-with-www.{yourdomain}>
pfxPath=<replace-with-path-to-your-.PFX-file>
pfxPassword=<replace-with-your=.PFX-password>
resourceGroup=myResourceGroup
webappname=mywebapp$RANDOM
# Create a resource group.

az group create --location westeurope --name $resourceGroup
# Create an App Service plan in Basic tier (minimum required by custom domains).
az appservice plan create --name $webappname --resource-group $resourceGroup --sku B1
# Create a web app.

az webapp create --name $webappname --resource-group $resourceGroup \
--plan $webappname
echo "Configure a CNAME record that maps $fqdn to $webappname.azurewebsites.net"

read -p "Press [Enter] key when ready ..."
# Before continuing, go to your DNS configuration UI for your custom domain and follow the
# instructions at https://aka.ms/appservicecustomdns to configure a CNAME record for the
# hostname "www" and point it your web app's default domain name.
# Map your prepared custom domain name to the web app.

az webapp config hostname add --webapp-name $webappname --resource-group $resourceGroup \
--hostname $fqdn
# Upload the SSL certificate and get the thumbprint.

thumbprint=$(az webapp config ssl upload --certificate-file $pfxPath \
--certificate-password $pfxPassword --name $webappname --resource-group $resourceGroup \
--query thumbprint --output tsv)
# Binds the uploaded SSL certificate to the web app.

az webapp config ssl bind --certificate-thumbprint $thumbprint --ssl-type SNI \
--name $webappname --resource-group $resourceGroup
echo "You can now browse to https://$fqdn"
PowerShell
$fqdn="<Replace with your custom domain name>"
$pfxPath="<Replace with path to your .PFX file>"
$pfxPassword="<Replace with your .PFX password>"
$webappname="mywebapp$(Get-Random)"
$location="West Europe"

New-AzResourceGroup -Name $webappname -Location $location
# Create an App Service plan in Free tier.

New-AzAppServicePlan -Name $webappname -Location $location `
-ResourceGroupName $webappname -Tier Free
# Create a web app.

New-AzWebApp -Name $webappname -Location $location -AppServicePlan $webappname `
-ResourceGroupName $webappname
Write-Host "Configure a CNAME record that maps $fqdn to $webappname.azurewebsites.net"

Read-Host "Press [Enter] key when ready ..."
# Upgrade App Service plan to Basic tier (minimum required by custom SSL certificates)
Set-AzAppServicePlan -Name $webappname -ResourceGroupName $webappname `
-Tier Basic
# Add a custom domain name to the web app.

Set-AzWebApp -Name $webappname -ResourceGroupName $webappname `
-HostNames @($fqdn,"$webappname.azurewebsites.net")
# Upload and bind the SSL certificate to the web app.

New-AzWebAppSSLBinding -WebAppName $webappname -ResourceGroupName $webappname -Name $fqdn `
-CertificateFilePath $pfxPath -CertificatePassword $pfxPassword -SslState SniEnabled
Mais recursos
Utilize um certificado TLS/SSL no seu código no Serviço de Aplicações Azure
FAQ : Certificados de serviço de aplicações
Tutorial: Adicionar a CDN do Azure a uma aplicação
Web do Serviço de Aplicações do Azure
Este tutorial mostra como adicionar a Rede de Entrega de Conteúdo (CDN) do Azure a uma aplicação Web no
Serviço de Aplicações do Azure. As Aplicações Web são um serviço para o alojamento de aplicações Web, APIs
REST e back-ends móveis.
Segue a home page do site HTML estático de exemplo com que irá trabalhar:
O que irá aprender:

Criar um ponto final da CDN.
Atualizar ativos em cache.
Utilize cadeias de consulta para controlar versões em cache.
Pré-requisitos
Instalar o Git
Instalar o Azure CLI
Criar a aplicação Web

Para criar a aplicação Web com que irá trabalhar, siga o início rápido HTML estático, através do passo Navegar
para a aplicação .
Iniciar sessão no portal do Azure

Abra um browser e navegue para o portal do Azure.
Otimização de aceleração de site dinâmico
Se quiser otimizar o seu ponto final de CDN para a aceleração de site dinâmica (DSA), deve utilizar o portal da CDN
para criar o seu perfil e o ponto final. Com otimização DSA, o desempenho das páginas web com o conteúdos
dinâmicos foi consideravelmente melhorado. Para obter instruções sobre como otimizar um ponto final de CDN
para DSA a partir do portal de CDN, veja Configuração do ponto final de CDN para acelerar a entrega de ficheiros
dinâmicos. Caso contrário, se não quiser otimizar o seu novo ponto final, pode utilizar o portal da aplicação Web
para criá-lo ao seguir os passos da próxima secção. Note que para os perfis de CDN do Azure da Verizon , não
pode alterar a otimização de um ponto final de CDN após ter sido criado.
Criar um perfil da CDN e ponto final

No painel de navegação esquerdo, selecione Ser viço de Aplicações e, em seguida, selecione a aplicação que
criou no início rápido HTML estático.
Na página Ser viço de Aplicações , na secção Definições , selecione Redes > Configurar a CDN do Azure
para a sua aplicação .
Na página Azure Content Deliver y Network (Rede de Entrega de Conteúdos do Azure), indique as definições
Novo ponto final conforme especificado na tabela.
Perfil da CDN myCDNProfile Um perfil da CDN é uma coleção de

pontos finais da CDN com o mesmo
escalão de preços.
Nível de preços Standard da Akamai O escalão de preço especifica o

fornecedor e as funcionalidades
disponíveis. Este tutorial utiliza o
Standard da Akamai.
Nome do ponto final da CDN Qualquer nome que é exclusivo no Acede aos seus recursos em cache no *
domínio azureedge.net <nome>final*de domínio
.azureedge.net.
Selecione Criar para criar um perfil de CDN.

O Azure cria o perfil e o ponto final. O novo ponto final é apresentado na lista Pontos finais e, quando está
aprovisionado, o estado é A executar .
Testar o ponto final da CDN
Dado que a propagação do registo demora algum tempo, o ponto final não está imediatamente disponível para
utilização:
Para os perfis CDN do Azure Standard da Microsoft , a propagação normalmente fica concluída em 10
minutos.
Para os perfis CDN do Azure Standard da Akamai , a propagação normalmente fica concluída num minuto.
Para os perfis CDN do Azure Standard da Verizon e CDN do Azure Premium da Verizon , a propagação
normalmente fica concluída no prazo de 90 minutos.
A aplicação de exemplo tem um ficheiro index.html e pastas css, img e js que contêm outros elementos estáticos.
Os caminhos de conteúdo para todos estes ficheiros são os mesmos no ponto final da CDN. Por exemplo, ambos
os seguintes URLs acedem ao ficheiro bootstrap.css na pasta css:
http://<appname>.azurewebsites.net/css/bootstrap.css
http://<endpointname>.azureedge.net/css/bootstrap.css
Navegue até um browser para o seguinte URL:
http://<endpointname>.azureedge.net/index.html
Será apresentada a mesma página que executou anteriormente numa aplicação Web do Azure. A CDN do Azure
obteve os ativos da aplicação Web de origem e está a servi-los a partir do ponto final da CDN
Para se certificar de que esta página está colocada em cache no CDN, atualize-a. Por vezes são necessários dois
pedidos para o mesmo recurso, para o CDN colocar em cache os conteúdos solicitados.
Para obter mais informações sobre a criação de perfis de CDN do Azure e os pontos finais, consulte Introdução ao
Azure CDN.
Remover a CDN
A CDN atualiza periodicamente os respetivos recursos da aplicação Web de origem consoante a configuração de
tempo de duração (TTL). O TTL predefinido é de sete dias.
Por vezes, poderá precisar de atualizar a CDN antes de expirar o TTL; por exemplo, ao implementar conteúdo
atualizado na aplicação Web. Para acionar uma atualização, remova manualmente os recursos da CDN.
Nesta secção do tutorial, implemente uma alteração na aplicação Web e remova o CDN para acionar o CDN para
atualizar a respetiva cache.
Implementar uma alteração na aplicação Web
Abra o ficheiro index.html e adicione -V2 ao cabeçalho H1, conforme mostrado no seguinte exemplo:
<h1>Azure App Service - Sample Static HTML Site - V2</h1>
Consolide as alterações e implemente-as na aplicação Web.
git commit -am "version 2"

Depois de concluída a implementação, navegue para o URL da aplicação Web para ver a alteração.
http://<appname>.azurewebsites.net/index.html
Se navegar para o URL de ponto final da CDN da home page, não verá a alteração porque a versão em cache na
CDN ainda não expirou.
Remova a CDN no portal

Para acionar a CDN para atualizar a versão em cache, remova a CDN.
Na navegação à esquerda do portal, selecione Grupos de recursos e, em seguida, selecione o grupo de recursos
que criou a sua aplicação Web (myResourceGroup).
Na lista de recursos, selecione o ponto final de CDN.
Na parte superior da página Ponto final , selecione Remover .
Introduza os caminhos do conteúdo que quer remover. Pode transmitir um caminho de ficheiro completo para
remover um ficheiro individual ou um segmento de caminho para remover e atualizar todo o conteúdo numa
pasta. Como alterou o index.html, certifique-se de que está num dos caminhos.
Na parte inferior da página, selecione Remover .
Certifique -se de que a CDN é atualizada
Aguarde até que o pedido de remoção conclua o processamento, que demora normalmente alguns minutos. Para
ver o estado atual, selecione o ícone da campainha na parte superior da página.
Ao navegar para o URL de ponto final da CDN para index.html, verá o V2 que adicionou ao título na home page,
que indica que a cache da CDN foi atualizada.
Para obter mais informações, consulte Remover um ponto final do Azure CDN.
Utilizar cadeias de consulta para o conteúdo da versão

A CDN do Azure oferece as seguintes opções de comportamento de colocação em cache:
Ignorar cadeias de consulta
Ignorar a colocação em cache de cadeias de consulta
Colocar em cache todos os URL exclusivos
A primeira opção é a predefinida, o que significa que existe apenas uma versão em cache de um ativo,
independentemente da cadeia de consulta no URL.
Nesta secção do tutorial, pode alterar o comportamento de colocação em cache para colocar em cache todos os
URL exclusivos.
Alterar o comportamento de cache
Na página Ponto Final CDN do portal do Azure, selecione Cache .
Selecione Colocar em cache todos os URL exclusivos relativo ao compor tamento de colocação em cache
da Cadeia de consulta na lista pendente.
Selecione Guardar .
Certifique -se de que os URL exclusivos são colocados em cache em separado

Num browser, navegue para a home page no ponto final da CDN e inclua uma cadeia de consulta:
http://<endpointname>.azureedge.net/index.html?q=1
A CDN do Azure devolve o conteúdo da aplicação Web atual, que inclui V2 no cabeçalho.
Para se certificar de que esta página está colocada em cache no CDN, atualize-a.
Abra index.html, altere V2 para V3 e, em seguida, implemente a alteração.
git commit -am "version 3"

Num browser, aceda ao URL de ponto final da CDN com uma nova cadeia de consulta, como q=2 . A CDN do Azure
obtém o ficheiro index.html atual e apresenta V3. No entanto, se navegar para o ponto final da CDN com a cadeia
de consulta q=1 , verá V2.
Este resultado mostra que cada cadeia de consulta é tratada de forma diferente:
q=1 foi utilizado antes, pelo que os conteúdos armazenados em cache são devolvidos (V2).
q=2 é novo, pelo que os conteúdos mais recentes da aplicação Web são obtidos e devolvidos (V3).
Para obter mais informações, consulte Control Azure CDN caching behavior with query strings(Controlar o
comportamento de colocação em cache do Azure CDN com cadeias de consulta).
Limpar recursos
Passos seguintes
O que aprendeu:
Criar um ponto final da CDN.
Atualizar ativos em cache.
Utilize cadeias de consulta para controlar versões em cache.
Saiba como otimizar o desempenho da CDN nos seguintes artigos:
Tutorial: Adicionar um domínio personalizado ao ponto final da CDN do Azure
Tutorial: Autenticar e autorizar utilizadores ponto a
ponto no Serviço de Aplicações do Azure
correção automática. Além disso, o Serviço de Aplicações tem suporte incorporado para autenticação e
autorização de utilizadores. Este tutorial mostra como proteger as suas aplicações com a autenticação e
autorização do Serviço de Aplicações. Usa uma aplicação ASP.NET Core com uma frente angular.js como exemplo.
A autenticação e autorização do Serviço de Aplicações suportam todos os runtimes de linguagens e pode seguir
o tutorial para aprender a aplicá-las na sua linguagem preferida.
Também lhe mostra como proteger uma aplicação multicamadas ao aceder a uma API de back-end protegida em
nome do utilizador autenticado, a partir de código do servidor e de código do browser.
Estes são apenas alguns dos cenários possíveis de autenticação e autorização no Serviço de Aplicações.
Eis uma lista mais completa do que vai aprender no tutorial:
Ativar a autenticação e autorização incorporadas
Proteger aplicações contra pedidos não autenticados
Utilizar o Azure Active Directory como o fornecedor de identidade
Aceder a uma aplicação remota em nome do utilizador com sessão iniciada
Proteger chamadas de serviço para serviço com a autenticação de tokens
Utilizar tokens de acesso a partir do código de servidor
Utilizar tokens de acesso a partir do código de cliente (browser)
Pode seguir os passos neste tutorial em macOS, Linux e Windows.
Pré-requisitos
Instalar o Git

Neste passo, vai configurar o projeto .NET Core local. Vai utilizar o mesmo projeto para implementar uma
aplicação API de back-end e uma aplicação Web de front-end.
Clonar e executar a aplicação de exemplo
Execute os seguintes comandos para clonar o repositório de exemplo e executá-lo.
git clone https://github.com/Azure-Samples/dotnet-core-api

cd dotnet-core-api
dotnet run
Navegue para http://localhost:5000 e experimente adicionar, editar e remover itens de afazeres.
Para parar o ASP.NET Core em qualquer altura, prima Ctrl+C no terminal.

comandos pré-instalados do Cloud Shell para executar o código neste artigo sem ter de instalar nada no
ambiente local.




Implementar aplicações no Azure

Neste passo, vai implementar o projeto em duas aplicações do Serviço de Aplicações. Uma é a aplicação de front-
end e a outra é a de back-end.
'@'.
Criar recursos do Azure
No Cloud Shell, execute os seguintes comandos para criar duas aplicações Web. Substitua a-z 0-9 - _ <_ o
nome da aplicação frontal>e _ <o nome da aplicação de back-end>_ por dois nomes de aplicativos globalmente
únicos (caracteres válidos são , e ). Para obter mais informações sobre cada comando, veja API RESTful com CORS
no Serviço de Aplicações do Azure.
az group create --name myAuthResourceGroup --location "West Europe"

az appservice plan create --name myAuthAppServicePlan --resource-group myAuthResourceGroup --sku FREE
az webapp create --resource-group myAuthResourceGroup --plan myAuthAppServicePlan --name <front-end-app-name>
--deployment-local-git --query deploymentLocalGitUrl
az webapp create --resource-group myAuthResourceGroup --plan myAuthAppServicePlan --name <back-end-app-name>
--deployment-local-git --query deploymentLocalGitUrl
NOTE
Guarde os URLs das instâncias remotas do Git para as aplicações de front-end e back-end, que são apresentados na saída
de az webapp create .

Novamente na janela de terminal local, execute os seguintes comandos do Git para implementar na aplicação de
back-end. Substitua _ <a implementaçãoLocalGitUrl-of-back-end-app>_ pelo URL do comando Git que guardou
dos recursos Create Azure. Quando solicitado para obter credenciais por Git Credential Manager, certifique-se de
que introduz as suas credenciaisde implantação , e não as credenciais que usa para iniciar sessão no portal Azure.
git remote add backend <deploymentLocalGitUrl-of-back-end-app>

git push backend master
Na janela de terminal do local, execute os seguintes comandos do Git para implementar o mesmo código na
aplicação de front-end. Substitua _ <a implementaçãoLocalGitUrl-of-front-end-app>_ com o URL do comando Git
que guardou dos recursos Create Azure.
git remote add frontend <deploymentLocalGitUrl-of-front-end-app>

git push frontend master
Navegue nas aplicações

Navegue para os seguintes URLs num browser e veja as duas aplicações a funcionar.
http://<back-end-app-name>.azurewebsites.net
http://<front-end-app-name>.azurewebsites.net
NOTE
Se a aplicação se reiniciar, poderá ter reparado que os dados novos foram apagados. Este comportamento é predefinido,
porque a aplicação ASP.NET Core de exemplo utiliza uma base de dados dentro da memória.
Chamar a API de back-end a partir do front-end

Neste passo, vai apontar o código do servidor da aplicação de front-end para aceder à API de back-end.
Posteriormente, vai ativar o acesso autenticado do front-end para o back-end.
Modificar o código de front-end
No repositório local, abra Controllers/TodoController.cs. No início da TodoController aula, adicione as seguintes
linhas e substitua _ <o nome_ da aplicação de back-end>com o nome da sua aplicação de back-end:
private static readonly HttpClient _client = new HttpClient();

private static readonly string _remoteUrl = "https://<back-end-app-name>.azurewebsites.net";
Encontre o método que está [HttpGet] decorado e substitua o código dentro do aparelho encaracolado com:
var data = await _client.GetStringAsync($"{_remoteUrl}/api/Todo");

return JsonConvert.DeserializeObject<List<TodoItem>>(data);
A primeira linha faz uma chamada de GET /api/Todo para a aplicação API de back-end.
Em seguida, encontre o método [HttpGet("{id}")] que está decorado e substitua o código dentro do aparelho
encaracolado por:
var data = await _client.GetStringAsync($"{_remoteUrl}/api/Todo/{id}");

return Content(data, "application/json");
A primeira linha faz uma chamada de GET /api/Todo/{id} para a aplicação API de back-end.
Em seguida, encontre o método [HttpPost] que está decorado e substitua o código dentro do aparelho
encaracolado por:
var response = await _client.PostAsJsonAsync($"{_remoteUrl}/api/Todo", todoItem);

var data = await response.Content.ReadAsStringAsync();
return Content(data, "application/json");
A primeira linha faz uma chamada de POST /api/Todo para a aplicação API de back-end.
Em seguida, encontre o método [HttpPut("{id}")] que está decorado e substitua o código dentro do aparelho
encaracolado por:
var res = await _client.PutAsJsonAsync($"{_remoteUrl}/api/Todo/{id}", todoItem);

return new NoContentResult();
A primeira linha faz uma chamada de PUT /api/Todo/{id} para a aplicação API de back-end.
Em seguida, encontre o método [HttpDelete("{id}")] que está decorado e substitua o código dentro do
aparelho encaracolado por:
var res = await _client.DeleteAsync($"{_remoteUrl}/api/Todo/{id}");

return new NoContentResult();
A primeira linha faz uma chamada de DELETE /api/Todo/{id} para a aplicação API de back-end.
Guarde todas as alterações. Na janela de terminal do local, implemente as alterações na aplicação de front-end
com os seguintes comandos do Git:
git add .
git commit -m "call back-end API"
Verificar as alterações
Navegue para http://<front-end-app-name>.azurewebsites.net e adicione alguns itens, como from front end 1 e
from front end 2 .
Navegue para http://<back-end-app-name>.azurewebsites.net para ver os itens adicionados a partir da aplicação

de front-end. Além disso, adicione alguns itens, como from back end 1 e from back end 2 e, depois, atualize a
aplicação de front-end para ver se reflete as alterações.
Configurar a autenticação
Neste passo, vai ativar a autenticação e autorização para as duas aplicações. Também vai configurar a aplicação
de front-end para gerar um token de acesso que pode utilizar para fazer chamadas autenticadas para a aplicação
de back-end.
Vai utilizar o Azure Active Directory como o fornecedor de identidade. Para obter mais informações, veja
Configure Azure Active Directory authentication for your App Services application (Configurar a autenticação do
Azure Active Directory na sua aplicação dos Serviços de Aplicação).
Ativar a autenticação e autorização na aplicação de back-end
No menu do portal Azure, selecione grupos de Recursos ou procure e selecione grupos de Recursos a partir de
qualquer página.
Em grupos de Recursos, encontre e selecione o seu grupo de recursos. Em resumo, selecione a página de
gestão da sua aplicação de back-end.
No menu esquerdo da sua aplicação de back-end, selecione Autenticação /Autorização e, em seguida, ative a
autenticação do serviço de aplicações selecionando On .
Em Ação a tomar quando o pedido não é autenticado , selecione Iniciar sessão com o Azure Active
Director y .
No âmbito dos Fornecedores de Autenticação, selecione Diretório Ativo Azure .
Selecione Express e, em seguida, aceite as definições padrão para criar uma nova aplicação AD e selecione OK .
Na página Autenticação/Autorização, selecione Guardar .
Assim que vir a Successfully saved the Auth Settings for <back-end-app-name> App notificação com a mensagem,
refresque a página do portal.
Selecione o Diretório Ativo Azure novamente e, em seguida, selecione a app Azure AD .
Copie a identificação do cliente da aplicação Azure AD para um bloco de notas. Vai precisar deste valor mais à
frente.
Se parar aqui, tem uma aplicação independente que já está assegurada pela autenticação e autorização do
Serviço de Aplicações. As restantes secções mostram-lhe como garantir uma solução multi-app "fluindo" o
utilizador autenticado da extremidade frontal para a extremidade traseira.
Ativar a autenticação e autorização na aplicação de front-end
Siga os mesmos passos para a aplicação de front-end, mas ignore o último. Não precisa da identificação do
cliente para a aplicação frontal.
Se preferir, navegue para http://<front-end-app-name>.azurewebsites.net . Deve ser agora direcionado para uma
página de início de sessão segura. Depois de iniciar sessão, ainda não consegue aceder aos dados da aplicação
back-end, porque a aplicação back-end agora requer o registo do Azure Ative Directory a partir da aplicação
frontal. Tens de fazer três coisas:
Conceder ao front-end o acesso ao back-end
Configurar o Serviço de Aplicações para devolver um token utilizável
Utilizar o token no seu código
TIP
Se se deparar com erros e reconfigurar as definições de autenticação/autorização da sua aplicação, os tokens no arquivo de
tokens poderão não ser regenerados a partir das definições novas. Para garantir que os tokens são regenerados, tem de
terminar sessão e reiniciá-la na aplicação. Uma forma fácil de fazê-lo é utilizar o browser no modo privado e fechá-lo e
reabri-lo no modo privado depois de alterar as definições nas suas aplicações.
Conceder ao front-end acesso ao back-end

Agora que ativou a autenticação e autorização em ambas as suas aplicações, cada uma destas está associada a
uma aplicação do AD. Neste passo, vai conceder à aplicação de front-end as permissões para aceder ao back-end
em nome do utilizador. (Tecnicamente, vai conceder à aplicação do AD de front-end as permissões para aceder à
aplicação do AD de back-end em nome do utilizador.)
No menu do portal Azure, selecione Azure Ative Director y ou procure e selecione Azure Ative Directory a
partir de qualquer página.
Selecione Registos de Aplicações > Aplicações Próprias > Ver todas as aplicações neste diretório .
Selecione o nome da aplicação frontal e, em seguida, selecione permissões API .
Selecione Adicionar uma permissão e, em seguida, selecione APIs a minha organização usa > <> de nome
de aplicação final .
Na página de permissões do Request API para a aplicação back-end, selecione permissões delegadas e
user_impersonation, em seguida, selecione Adicionar permissões .
Configurar o Serviço de Aplicações para devolver um token de acesso utilizável

A aplicação frontal tem agora as permissões necessárias para aceder à aplicação back-end como utilizador
inscrito. Neste passo, vai configurar a autenticação e autorização do Serviço de Aplicações para lhe dar um token
de acesso utilizável para aceder ao back-end. Para este passo, precisa do ID do cliente do back end, que copiou da
autenticação Enable e autorização para aplicação back-end.
No menu esquerdo da sua aplicação frontal, selecione Resource Explorer em Ferramentas de
Desenvolvimento e, em seguida, selecione Go .
O Azure Resource Explorer foi agora aberto com a sua aplicação frontal selecionada na árvore de recursos. Na
parte superior da página, clique em Leitura/Escrita para ativar a edição dos seus recursos do Azure.
No navegador esquerdo, faça uma broca atéauthsettings de config > .
Na vista authsettings , clique em Editar . Desloque-se additionalLoginParams para a seguinte corda JSON,
utilizando o ID do cliente copiado.
"additionalLoginParams": ["response_type=code id_token","resource=<back-end-client-id>"],
Clique em PUT para guardar as definições.

As suas aplicações estão agora configuradas. O front-end está agora pronto para aceder ao back-end com um
token de acesso correto.
Para obter informações sobre como configurar o sinal de acesso para outros fornecedores, consulte fichasdo
fornecedor de identidade Refresh .
Chamar a API de forma segura a partir do código de servidor

Neste passo, vai ativar o código de servidor modificado anteriormente para fazer chamadas autenticadas para a
API de back-end.
A sua aplicação frontal tem agora a permissão necessária e também adiciona o ID do cliente da parte de trás aos
parâmetros de login. Por conseguinte, pode obter um token de acesso para a autenticação na aplicação de back-
end. O Serviço de Aplicações fornece este token ao código de servidor mediante a injeção de um cabeçalho
X-MS-TOKEN-AAD-ACCESS-TOKEN em cada pedido autenticado (veja Retrieve tokens in app code [Obter tokens no
código da aplicação]).
NOTE
Estes cabeçalhos são injetados em todas as linguagens suportadas. Pode aceder aos mesmos através da norma padrão de
cada linguagem.
No repositório local, abra novamente Controllers/TodoController.cs. No construtor

TodoController(TodoContext context) , adicione o seguinte código:
public override void OnActionExecuting(ActionExecutingContext context)

{
base.OnActionExecuting(context);
_client.DefaultRequestHeaders.Accept.Clear();
_client.DefaultRequestHeaders.Authorization =
new AuthenticationHeaderValue("Bearer", Request.Headers["X-MS-TOKEN-AAD-ACCESS-TOKEN"]);
}
Este código adiciona o cabeçalho HTTP padrão Authorization: Bearer <access-token> a todas as chamadas à API
remotas. No ASP.NET Core MVC solicitar OnActionExecuting o gasoduto de execução, executa pouco antes da
respetiva ação, pelo que cada uma das suas chamadas api cessantes apresenta agora o sinal de acesso.
git add .
git commit -m "add authorization header for server code"
Volte a iniciar sessão em https://<front-end-app-name>.azurewebsites.net . Na página do contrato de utilização de

dados do utilizador, clique em Aceitar .
Deverá ser agora capaz de criar, ler, atualizar e eliminar os dados da aplicação de back-end como antes. A única
diferença é que agora ambas as aplicações estão protegidas através da autenticação e autorização do Serviço de
Aplicações, incluindo as chamadas de serviço para serviço.
Parabéns! O código de servidor está agora a aceder aos dados do back-end em nome do utilizador autenticado.
Chamar a API de forma segura a partir do código do browser

Neste passo, vai apontar a aplicação Angular.js de front-end para a API de back-end. Desta forma, aprenderá a
obter o token de acesso e a fazer chamadas à API para a aplicação de back-end com o mesmo.
Embora o código do servido tenha acesso aos cabeçalhos dos pedidos, o código do cliente pode aceder a
GET /.auth/me para obter os mesmos tokens de acesso (veja Retrieve tokens in app code [Obter tokens no
código da aplicação]).
TIP
Esta secção utiliza os métodos HTTP padrão para demonstrar as chamadas HTTP seguras. No entanto, pode utilizar a
Microsoft Authentication Library para o JavaScript para ajudar a simplificar o padrão de aplicação Angular.js.
Configurar o CORS
Na Cloud Shell, ative o CORS no URL az webapp cors add do seu cliente utilizando o comando. Substitua _ <_ o
nome da aplicação de trás para a frente>e _ <_ o nome da aplicação frontal>espaços reservados.
az webapp cors add --resource-group myAuthResourceGroup --name <back-end-app-name> --allowed-origins

'https://<front-end-app-name>.azurewebsites.net'
Este passo não está relacionado com a autenticação e autorização. No entanto, tem de segui-lo para que o
browser possa permitir as chamadas à API em vários domínios a partir da aplicação Angular.js. Para obter mais
informações, veja Adicionar a funcionalidade CORS.
Apontar a aplicação Angular.js para a API de back-end
No repositório local, abra wwwroot/index.html.
Na Linha 51, apiEndpoint delineie a variável para https://<back-end-app-name>.azurewebsites.net o URL HTTPS da
sua aplicação back-end (). Substitua>de nome de aplicação de _ <back-end_ com o nome da aplicação no Serviço
de Aplicações.
No repositório local, abra wwwroot/app/scripts/todoListSvc.js e verifique se apiEndpoint está anexado a todas as
chamadas à API. A sua aplicação Angular.js está agora a chamar as APIs de back-end.
Adicionar o token de acesso às chamadas à API
Em wwwroot/app/scripts/todoListSvc.js, acima da lista de chamadas à API (em cima da linha
getItems : function(){ ), adicione a seguinte função à lista:
setAuth: function (token) {
$http.defaults.headers.common['Authorization'] = 'Bearer ' + token;
},
Esta função é chamada para definir o cabeçalho Authorization predefinido com o token de acesso. Vai chamá-la
no próximo passo.
No repositório local, abra wwwroot/app/scripts/app.js e localize o seguinte código:
$routeProvider.when("/Home", {
controller: "todoListCtrl",
templateUrl: "/App/Views/TodoList.html",
}).otherwise({ redirectTo: "/Home" });
Substitua o bloco de código inteiro pelo código abaixo:
$routeProvider.when("/Home", {
controller: "todoListCtrl",
templateUrl: "/App/Views/TodoList.html",
resolve: {
token: ['$http', 'todoListSvc', function ($http, todoListSvc) {
return $http.get('/.auth/me').then(function (response) {
todoListSvc.setAuth(response.data[0].access_token);
return response.data[0].access_token;
});
}]
},
}).otherwise({ redirectTo: "/Home" });
A nova alteração adiciona o mapeamento resolve que chama /.auth/me e define o token de acesso. Confirma
que tem o token de acesso antes de instanciar o controlador todoListCtrl . Dessa forma, todas as chamadas à
API pelo controlador incluem o token.
Implementar as atualizações e testar
git add .
git commit -m "add authorization header for Angular"
Navegue novamente até https://<front-end-app-name>.azurewebsites.net . Deverá ser agora capaz de criar, ler,
atualizar e eliminar os dados da aplicação de back-end, diretamente na aplicação Angular.js.
Parabéns! O código do cliente está agora a aceder aos dados do back-end em nome do utilizador autenticado.
Quando o token de acesso expira

O token de acesso expira ao fim de algum tempo. Para obter informações sobre como atualizar os seus tokens de
acesso sem exigir que os utilizadores se reatentam com a sua aplicação, consulte fichasdo fornecedor de
identidade Refresh .
Limpar recursos
az group delete --name myAuthResourceGroup
Passos seguintes
O que aprendeu:
Ativar a autenticação e autorização incorporadas
Proteger aplicações contra pedidos não autenticados
Utilizar o Azure Active Directory como o fornecedor de identidade
Aceder a uma aplicação remota em nome do utilizador com sessão iniciada
Proteger chamadas de serviço para serviço com a autenticação de tokens
Utilizar tokens de acesso a partir do código de servidor
Utilizar tokens de acesso a partir do código de cliente (browser)
Avance para o próximo tutorial para aprender a mapear um nome DNS personalizado para a sua aplicação.
Tutorial: Envie e-mail e invoque outros processos de
negócio do App Service
Neste tutorial, aprende a integrar a sua app de Serviço de Aplicações com os seus processos de negócio. Isto é
comum a cenários de aplicações web, tais como:
Enviar e-mail de confirmação para uma transação
Adicionar utilizador ao grupo do Facebook
Ligue-se a sistemas de terceiros como SAP, SalesForce, etc.
Trocar mensagens B2B padrão
Neste tutorial, envia e-mails com o Gmail a partir da sua app App Service utilizando aplicações da Azure Logic.
Existem outras formas de enviar e-mails de uma aplicação web, como a configuração SMTP fornecida pelo seu
enquadramento linguístico. No entanto, as Aplicações Lógicas trazem muito mais energia à sua aplicação App
Service sem adicionar complexidade ao seu código. Logic Apps fornece uma interface de configuração simples para
as integrações de negócios mais populares, e a sua aplicação pode chamá-las a qualquer momento com um pedido
HTTP.
Pré-requisito
Implemente uma aplicação com o enquadramento linguístico da sua escolha para o App Service. Para seguir um
tutorial para implementar uma aplicação de amostra, consulte abaixo:
ASP.NET
ASP.NET Core
Node.js
PHP
Python
Ruby
Tutorial: Criar uma aplicação ASP.NET no Azure com a Base de Dados SQL
Criar a App Lógica

1. No portal Azure, crieuma aplicação lógica vazia seguindo as instruções na Create your logic app. Quando vir
o Designer de Aplicações Lógicas, volte a este tutorial.
2. Na página de splash para Logic Apps Designer, selecione Quando um pedido HTTP é recebido em Iniciar
com um gatilho comum .
3. No diálogo para Quando um pedido HTTP é recebido, selecione Utilize a carga útil da amostra para
gerar esquema .
4. Copie a amostra seguinte JSON na caixa de texto e selecione Done .
{
"task": "<description>",
"due": "<date>",
"email": "<email-address>"
}
O esquema é agora gerado para os dados de pedido que pretende. Na prática, pode simplesmente capturar
os dados de pedidos reais que o seu código de aplicação gera e deixar que o Azure gere o esquema JSON
para si.
5. No topo do Logic Apps Designer, selecione Save .
Pode agora ver o URL do seu gatilho de pedido HTTP. Selecione o ícone da cópia para copiá-lo para posterior
utilização.
Esta definição de pedido http é um gatilho para qualquer coisa que você quer fazer nesta aplicação lógica,
seja o Gmail ou qualquer outra coisa. Mais tarde, irá invocar este URL na sua aplicação App Service. Para
obter mais informações sobre o gatilho do pedido, consulte a referência de pedido/resposta HTTP.
6. Na parte inferior do designer, clique em Novo passo, digite o Gmail na caixa de pesquisa de ações e
encontre e selecione Enviar e-mail (V2) .
TIP
Pode procurar outros tipos de integrações, tais como SendGrid, MailChimp, Office 365 e SalesForce. Para mais
informações, consulte a documentação das Aplicações Lógicas.
7. No diálogo gmail, selecione Iniciar sessão e iniciar sessão na conta do Gmail a partir da sua deseja enviar
o e-mail.
8. Uma vez inscrito, clique na caixa de texto para e o diálogo de conteúdo dinâmico é automaticamente aberto.
9. Junto ao pedido Quando um pedido HTTP é recebido, selecione Ver mais .
Deverá agora ver as três propriedades dos dados json da sua amostra que utilizou anteriormente. Neste
passo, utiliza estas propriedades a partir do pedido http para construir um e-mail.
10. Uma vez que está a selecionar o valor para o campo To, escolha e-mail . Se desejar, altere o diálogo de
conteúdo dinâmico clicando em Adicionar conteúdo dinâmico .
11. No add novo parâmetro dropdown, selecione Assunto e Corpo .

12. Clique na caixa de texto do Assunto e, da mesma forma, escolha a tarefa . Com o cursor ainda na caixa do
Assunto, o tipo criado.
13. Clique no Corpo , e da mesma forma, escolha o devido . Mova o cursor para a esquerda do devido e
escreva Este artigo de trabalho deve-se .
TIP
Se quiser editar conteúdo HTML diretamente no corpo de e-mail, selecione a vista de Código no topo da janela
Logic Apps Designer. Basta certificar-se de que preserva o @{triggerBody()?['due']} código de conteúdo dinâmico
(por exemplo, )
14. Em seguida, adicione uma resposta http assíncrona ao gatilho HTTP. Entre o gatilho HTTP e a + ação do
Gmail, clique no sinal e selecione Adicionar um ramo paralelo .
15. Na caixa de pesquisa, procure resposta e, em seguida, selecione a ação Resposta.

Por padrão, a ação de resposta envia um HTTP 200. É bom o suficiente para este tutorial. Para mais
informações, consulte a referência http/resposta.
16. No topo do Logic Apps Designer, selecione Save novamente.
Adicione código de pedido HTTP à app

Certifique-se de que copiou o URL do gatilho de pedido HTTP de há pouco. Como contém informação sensível, é a
melhor prática que não a coloque diretamente no código. Com o Serviço de Aplicações, pode referenciar como
uma variável ambiental, utilizando as definições da aplicação.
Na Cloud Shell,crie a definição da aplicação * < *com o seguinte comando (substitua * <o nome da aplicação>,
*>de nome de grupo de recursos e>de>de * <aplicações lógicas): *
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings

LOGIC_APP_URL="<your-logic-app-url>"
No seu código, faça um post HTTP padrão no URL utilizando qualquer idioma cliente HTTP que esteja disponível
para o seu quadro linguístico, com a seguinte configuração:
O organismo de pedido contém o mesmo formato JSON que forneceu à sua aplicação lógica:
{
"task": "<description>",
"due": "<date>",
"email": "<email-address>"
}
O pedido contém Content-Type: application/json a rubrica .

Para otimizar o desempenho, envie o pedido sincronicamente, se possível.
Clique no separador idioma/quadro preferido abaixo para ver um exemplo.
ASP.NET
ASP.NET Core
Node.js
PHP
Python
Ruby
Em ASP.NET, pode enviar o post HTTP com a classe System.Net.Http.HttpClient. Por exemplo:
// requires using System.Net.Http;
var client = new HttpClient();
// requires using System.Text.Json;
var jsonData = JsonSerializer.Serialize(new
{
email = "a-valid@emailaddress.com",
due = "4/1/2020",
task = "My new task!"
});
HttpResponseMessage result = await client.PostAsync(

// requires using System.Configuration;
ConfigurationManager.AppSettings["LOGIC_APP_URL"],
new StringContent(jsonData, Encoding.UTF8, "application/json"));
var statusCode = result.StatusCode.ToString();
Se estiver a testar este código na aplicação de amostras para tutorial: Construa uma aplicação ASP.NET em
Azurecom Todo base de dados SQL, poderá usá-lo para enviar uma confirmação de e-mail na ação Create, depois
de adicionado o item. Para utilizar o código assíncrono acima, converta a ação Create em assíncrona.
Mais recursos
Tutorial: Alojar uma API RESTful com CORS no Serviço de Aplicações do Azure
HTTP pedido/referência de resposta para Aplicações Lógicas
Quickstart: Crie o seu primeiro fluxo de trabalho utilizando aplicações da Azure Logic - portal Azure
Amostras cli para serviço de aplicações Azure
A tabela seguinte inclui ligações para scripts bash criados com a CLI do Azure.
Criar aplicação
Criar uma aplicação e implementar ficheiros com FTP Cria uma aplicação de Serviço de Aplicações e implementa um
ficheiro utilizando FTP.
Criar uma aplicação e implementar código a partir do GitHub Cria uma aplicação de Serviço de Aplicações e implementa
código a partir de um repositório público do GitHub.
Criar uma app com implantação contínua do GitHub Cria uma aplicação de Serviço de Aplicações com publicação
contínua a partir de um repositório GitHub que possui.
Criar uma aplicação e implementar código a partir de um Cria uma aplicação de Serviço de Aplicações e configura o
repositório git local code push de um repositório git local.
Criar uma app e implementar código para um ambiente de Cria uma aplicação de Serviço de Aplicações com uma ranhura
encenação de implementação para a realização de alterações de código.
Crie uma aplicação ASP.NET Core num recipiente Dodocker Cria uma aplicação de Serviço de Aplicações no Linux e
carrega uma imagem do Docker do Docker Hub.
Mapear um domínio personalizado para uma aplicação Cria uma aplicação de Serviço de Aplicações e mapeia-lhe um
nome de domínio personalizado.
Ligue um certificado Personalizado TLS/SSL a uma aplicação Cria-lhe uma aplicação de Serviço de Aplicações e liga-lhe o
certificado TLS/SSL de um nome de domínio personalizado.
Escala risadamente uma aplicação Cria uma aplicação de Serviço de Aplicações e escala-a em 2
instâncias.
Escala uma app em todo o mundo com uma arquitetura de Cria duas aplicações do App Service em duas regiões
alta disponibilidade geográficas diferentes e disponibiliza-as através de um único
ponto final usando o Azure Traffic Manager.
Proteger app
Integrar com o Portal de Aplicação Azure Cria uma aplicação de Serviço de Aplicações e integra-a com o
Application Gateway utilizando restrições de ponto final de
serviço e acesso.
Ligar aplicação aos recursos

Ligue uma aplicação a uma Base de Dados SQL Cria uma aplicação de Serviço de Aplicações e uma base de
dados SQL e, em seguida, adiciona a cadeia de ligação à base
de dados às definições da aplicação.
Ligar uma aplicação a uma conta de armazenamento Cria uma aplicação do Serviço de Aplicações e uma conta de
armazenamento e, em seguida, adiciona a cadeia de ligação de
armazenamento às definições da aplicação.
Ligue uma aplicação a um Azure Cache para Redis Cria uma aplicação de Serviço de Aplicações e um Cache
Azure para Redis, em seguida, adiciona os detalhes da ligação
redis às definições da aplicação.)
Ligue uma aplicação ao Cosmos DB Cria uma aplicação de Serviço de Aplicações e um Cosmos DB,
depois adiciona os detalhes da ligação Cosmos DB às
definições da aplicação.
Back up e restaurar app
Efetuar cópia de segurança de uma aplicação Cria uma aplicação de Serviço de Aplicações e cria uma cópia
de segurança única para o mesmo.
Criar um backup agendado para uma aplicação Cria uma aplicação de Serviço de Aplicações e cria uma cópia
de segurança agendada para o mesmo.
Restaura uma aplicação a partir de uma cópia de segurança Restaura uma aplicação do Serviço de Aplicações a partir de
uma cópia de segurança.
Monitorize uma aplicação com registos de servidores web Cria uma aplicação de Serviço de Aplicações, permite o registo
e descarrega os registos para a sua máquina local.
Amostras powerShell para serviço de aplicações
Azure
A tabela seguinte inclui links para scripts PowerShell construídos com o Azure PowerShell.
Criar aplicação
Criar uma aplicação com implementação do GitHub Cria uma aplicação de Serviço de Aplicações que retira código
do GitHub.
Criar uma app com implantação contínua do GitHub Cria uma aplicação de Serviço de Aplicações que implementa
continuamente código a partir do GitHub.
Criar uma app e implementar código com FTP Cria uma aplicação de Serviço de Aplicações e faz upload de
ficheiros de um diretório local utilizando FTP.
Criar uma aplicação e implementar código a partir de um Cria uma aplicação de Serviço de Aplicações e configura o
repositório git local code push de um repositório git local.
Criar uma app e implementar código para um ambiente de Cria uma aplicação de Serviço de Aplicações com uma ranhura
encenação de implementação para a realização de alterações de código.
Mapear um domínio personalizado para uma aplicação Cria uma aplicação de Serviço de Aplicações e mapeia-lhe um
nome de domínio personalizado.
Ligue um certificado Personalizado TLS/SSL a uma aplicação Cria-lhe uma aplicação de Serviço de Aplicações e liga-lhe o
certificado TLS/SSL de um nome de domínio personalizado.
Escala risadamente uma aplicação Cria uma aplicação de Serviço de Aplicações e escala-a em 2
instâncias.
Escala uma app em todo o mundo com uma arquitetura de Cria duas aplicações do App Service em duas regiões
alta disponibilidade geográficas diferentes e disponibiliza-as através de um único
ponto final usando o Azure Traffic Manager.
Ligar aplicação aos recursos
Ligue uma aplicação a uma Base de Dados SQL Cria uma aplicação de Serviço de Aplicações e uma base de
dados SQL e, em seguida, adiciona a cadeia de ligação à base
de dados às definições da aplicação.
Ligar uma aplicação a uma conta de armazenamento Cria uma aplicação do Serviço de Aplicações e uma conta de
armazenamento e, em seguida, adiciona a cadeia de ligação de
armazenamento às definições da aplicação.
Back up e restaurar app
Efetuar cópia de segurança de uma aplicação Cria uma aplicação de Serviço de Aplicações e cria uma cópia
de segurança única para o mesmo.
Criar um backup agendado para uma aplicação Cria uma aplicação de Serviço de Aplicações e cria uma cópia
de segurança agendada para o mesmo.
Eliminar uma cópia de segurança para uma aplicação Elimina uma cópia de segurança existente para uma aplicação.
Restaurar uma aplicação a partir de backup Restaura uma aplicação a partir de uma cópia de segurança
previamente concluída.
Restaurar um backup através de subscrições Restaura uma aplicação web a partir de uma cópia de
segurança em outra subscrição.
Monitorize uma aplicação com registos de servidores web Cria uma aplicação de Serviço de Aplicações, permite o registo
e descarrega os registos para a sua máquina local.
Modelos de Gestor de Recursos Azure para serviço
de aplicações
A tabela seguinte inclui links para modelos de Gestor de Recursos Azure para o Serviço de Aplicações Azure. Para
recomendações sobre como evitar erros comuns ao criar modelos de aplicações, consulte orientação sobre a
implementação de aplicações com modelosde Gestor de Recursos Azure .
Para conhecer a sintaxe jSON e propriedades para recursos de Serviços de Aplicações, consulte os tipos de recursos
Microsoft.Web.
Implementação de uma aplicação
Plano de serviço de aplicativos e aplicativo básico linux Implementa uma aplicação de Serviço de Aplicações que está
configurada para o Linux.
Plano de serviço de aplicativos e aplicativo básico do Windows Implementa uma aplicação do Serviço de Aplicações que está
configurada para windows.
App ligada a um repositório GitHub Implementa uma aplicação do App Service que retira código
do GitHub.
App com ranhuras de implementação personalizadas Implementa uma aplicação de Serviço de Aplicações com
ranhuras/ambientes de implementação personalizadas.
Configurar uma aplicação
Certificado de aplicativo de Key Vault Implementa um certificado de aplicação do App Service a

partir de um segredo azure Key Vault e usa-o para ligação
TLS/SSL.
App com um domínio personalizado Implementa uma aplicação de Serviço de Aplicações com um
nome de anfitrião personalizado.
App com domínio personalizado e SSL Implementa uma aplicação de Serviço de Aplicações com um
nome de anfitrião personalizado e obtém um certificado de
aplicação da Key Vault para a ligação TLS/SSL.
App com extensão GoLang Implementa uma aplicação de Serviço de Aplicações com a
extensão do site Golang. Em seguida, pode executar as
aplicações Web desenvolvidas no Golang no Azure.
App com Java 8 e Tomcat 8 Implementa uma aplicação de Serviço de Aplicações com Java
8 e Tomcat 8 ativado. Em seguida, pode executar aplicações
Java no Azure.
App com integração regional vNet Implementa uma aplicação de Serviço de Aplicações com
integração vnet regional ativada.
Proteger uma aplicação

App integrada com Gateway de Aplicação Azure Implementa uma aplicação de Serviço de Aplicações e um
Gateway de Aplicações, e isola o tráfego usando o ponto final
do serviço e restrições de acesso.
Aplicativo Linux com recursos conectados
App em Linux com MySQL Implementa uma aplicação de serviço de aplicações no Linux
com base de dados Azure para MySQL.
App em Linux com PostgreSQL Implementa uma aplicação de Serviço de Aplicações no Linux
com base de dados Azure para PostgreSQL.
App com recursos conectados
App com MySQL Implementa uma aplicação de serviço de aplicações no

Windows com base de dados Azure para MySQL.
App com PostgreSQL Implementa uma aplicação de serviço de aplicações no

Windows com base de dados Azure para PostgreSQL.
App com base de dados SQL Implementa uma aplicação de Serviço de Aplicações e uma
base de dados SQL ao nível básico de serviço.
App com uma conexão de armazenamento Blob Implementa uma aplicação de Serviço de Aplicações com uma
cadeia de conexão de armazenamento Azure Blob. Em seguida,
pode utilizar o armazenamento Blob a partir da aplicação.
App com um Cache Azure para Redis Implementa uma aplicação de Serviço de Aplicações com um
Azure Cache para Redis.
Ambiente do Ser viço de Aplicações
Criar um Ambiente de Serviço de Aplicações v2 Cria um ambiente de Serviço de Aplicações v2 na sua rede
virtual.
Criar um ambiente de Serviço de Aplicações v2 com um Cria um ambiente de Serviço de Aplicações v2 na sua rede
endereço ILB virtual com um endereço de balanceador de carga interno
privado.
Configura o certificado SSL predefinido para um ambiente de Configura o certificado padrão TLS/SSL para um ambiente de
Serviço de Aplicações ILB ou um ambiente de Serviço de serviço de aplicações ILB ou um ambiente de serviço de
Aplicações v2 ILB aplicações ILB v2.
Definições políticas incorporadas da Azure Policy
para o Azure App Service
Esta página é um índice de definições de política incorporadas da Azure Policy para o Azure App Service. Para obter
mais incorporados em Azure Policy para outros serviços, consulte definições incorporadas da Política Azure.
O nome de cada definição de política incorporada liga-se à definição de política no portal Azure. Utilize o link na
coluna GitHub para ver a fonte no repo GitHub da Política Azure.
Serviço de Aplicações do Azure

NAME DESC RIÇ Ã O EF EITO ( S) VERSÃ O GIT H UB
A API App só deve A utilização do HTTPS Auditoria, Deficientes 1.0.0 Ligação

estar acessível em garante a
HTTPS autenticação do
servidor/serviço e
protege os dados em
trânsito contra
ataques de escutas de
camadas de rede.
O Serviço de Esta política audita AuditIfNotExists, 1.0.0 Ligação

Aplicações deve qualquer Serviço de Desativado
utilizar um ponto final Aplicações não
de serviço de rede configurado para
virtual utilizar um ponto final
de serviço de rede
virtual.
A autenticação deve A Azure App Service AuditIfNotExists, 1.0.0 Ligação

ser ativada na sua Authentication é uma Desativado
aplicação API funcionalidade que
pode impedir que
pedidos anónimos de
HTTP cheguem à
aplicação API, ou
autenticar aqueles
que têm fichas antes
de chegarem à app
API

aplicação Função funcionalidade que
pode impedir que
HTTP cheguem à
aplicação Function, ou
autenticar aqueles
de chegarem à
aplicação Função

aplicação web funcionalidade que
pode impedir que
HTTP cheguem à
aplicação web, ou
autenticar aqueles
de chegarem à
aplicação web
O CORS não deve A Partilha de Recursos AuditIfNotExists, 1.0.0 Ligação

permitir que todos os de Origem Cruzada Desativado
recursos acedam à (CORS) não deve
sua App API permitir que todos os
domínios acedam à
sua aplicação API.
Permitir que apenas
os domínios
necessários interajam
com a sua aplicação
API.

recursos acedam às (CORS) não deve
suas Apps de Função permitir que todos os
domínios acedam à
sua aplicação
Function. Permitir que
apenas os domínios
Função.

recursos acedam às (CORS) não deve
suas Aplicações Web permitir que todos os
domínios acedam à
sua aplicação web.
Permitir que apenas
os domínios
web.
Os registos de Auditoria habilitando AuditIfNotExists, 1.0.0 Ligação

diagnóstico nos registos de Desativado
Serviços de Aplicações diagnóstico na
devem ser ativados aplicação. Isto
permite-lhe recriar
pistas de atividade
para fins de
investigação se
ocorrer um incidente
de segurança ou se a
sua rede estiver
comprometida
Garantir que a Os certificados de Auditoria, Deficientes 1.0.0 Ligação

aplicação da API tem cliente permitem que
"Certificados de a app solicite um
Cliente (Certificados certificado para
de cliente incoming)" pedidos de entrada.
definidos para 'On' Apenas os clientes
que tenham um
certificado válido
poderão chegar à
aplicação.

aplicação 'Certificados cliente permitem que
de Cliente ' a app solicite um
(certificados de cliente certificado para
incoming)' definidos pedidos de entrada.
para 'On' Apenas os clientes
que tenham um
certificado válido
poderão chegar à
aplicação.
Certifique-se de que a Periodicamente, as AuditIfNotExists, 1.0.0 Ligação

versão ".NET versões mais recentes Desativado
Framework" é a mais são lançadas para
recente, se usada software .NET
como parte da Framework, quer
aplicação API devido a falhas de
segurança, quer para
incluir funcionalidades
adicionais.
Recomenda-se a
utilização da versão
quadro .NET mais
recente para
aplicações web, de
forma a tirar partido
das correções de
segurança, caso
existam, e/ou novas
funcionalidades da
versão mais recente.

versão '.NET versões mais recentes Desativado
Framework' é a mais são lançadas para
como parte da App Framework, quer
de Função devido a falhas de
adicionais.
Recomenda-se a
quadro .NET mais
recente para
das correções de
segurança, caso
existam, e/ou novas
funcionalidades da

versão '.NET versões mais recentes Desativado
Framework' é a mais são lançadas para
como parte da Framework, quer
aplicação Web devido a falhas de
adicionais.
Recomenda-se a
quadro .NET mais
recente para
das correções de
segurança, caso
existam, e/ou novas
funcionalidades da
Certifique-se de que Periodicamente, as AuditIfNotExists, 1.0.0 Ligação

'VERSÃO HTTP' é a versões mais recentes Desativado
mais recente, se são lançadas para
usada para executar a HTTP, seja devido a
aplicação Api falhas de segurança
ou para incluir
funcionalidades
adicionais. Utilizando
a versão HTTP mais
recente para
aplicações web para
tirar partido das
correções de
segurança, caso
existam, e/ou novas
funcionalidades da

'versão HTTP' é a mais versões mais recentes Desativado
recente, se usada para são lançadas para
executar a aplicação HTTP, seja devido a
'Função' falhas de segurança
ou para incluir
funcionalidades
adicionais. Utilizando
a versão HTTP mais
recente para
aplicações web para
tirar partido das
correções de
segurança, caso
existam, e/ou novas
funcionalidades da
Certifique-se de que A identidade gerida AuditIfNotExists, 1.0.0 Ligação

'VERSÃO HTTP' é a do serviço no Serviço Desativado
mais recente, se de Aplicações torna a
usada para executar a app mais segura
aplicação Web eliminando segredos
da aplicação, como
credenciais nas cordas
de ligação. Ao
registar-se com o
Azure Ative Directory
no serviço de
aplicações, a aplicação
irá ligar-se a outros
serviços Azure de
forma segura, sem a
necessidade de nome
de utilizador e
palavras-passe.

'Versão Java' é a mais versões mais recentes Desativado
recente, se usada são lançadas para a
como parte da app Java, seja devido a
Api falhas de segurança
ou para incluir
funcionalidades
adicionais. A utilização
da versão python
mais recente para
aplicações Api é
recomendada de
das correções de
segurança, caso
existam, e/ou novas
funcionalidades da

recente, se usada são lançadas para o
como parte da software Java, seja
aplicação Function devido a falhas de
segurança ou para
da versão java mais
recente para
aplicações function é
recomendada de
das correções de
segurança, caso
existam, e/ou novas
funcionalidades da

recente, se usada são lançadas para o
como parte da software Java, seja
segurança ou para
da versão java mais
recente para
aplicações web é
recomendada de
das correções de
segurança, caso
existam, e/ou novas
funcionalidades da

'versão PHP' é a mais versões mais recentes Desativado
recente, se usada são lançadas para
como parte da software PHP, seja
aplicação Api devido a falhas de
segurança ou para
adicionais.
Recomenda-se a
PHP mais recente
para aplicações API,
de forma a tirar
partido das correções
de segurança, caso
existam, e/ou novas
funcionalidades da

segurança ou para
adicionais.
Recomenda-se a
PHP mais recente
para aplicações
function, de forma a
tirar partido das
correções de
segurança, caso
existam, e/ou novas
funcionalidades da

aplicação WEB devido a falhas de
segurança ou para
adicionais.
Recomenda-se a
PHP mais recente
para aplicações web,
de forma a tirar
partido das correções
de segurança, caso
existam, e/ou novas
funcionalidades da

'Python version' é a versões mais recentes Desativado
mais recente, se são lançadas para o
usada como parte da software Python, seja
app Api devido a falhas de
segurança ou para
da versão python
mais recente para
aplicações Api é
recomendada de
das correções de
segurança, caso
existam, e/ou novas
funcionalidades da

'Versão Python' é a versões mais recentes Desativado
segurança ou para
da versão python
mais recente para
aplicações function é
recomendada de
das correções de
segurança, caso
existam, e/ou novas
funcionalidades da

'Python version' é a versões mais recentes Desativado
segurança ou para
da versão python
mais recente para
aplicações web é
recomendada de
das correções de
segurança, caso
existam, e/ou novas
funcionalidades da

o Registo com o do serviço no Serviço Desativado
Diretório Ativo Azure de Aplicações torna a
está ativado na app mais segura
aplicação API eliminando segredos
de ligação. Ao
registar-se com o
no serviço de
serviços Azure de
forma segura, sem a
necessidade de nome
de utilizador e
palavras-passe.

Diretório Ativo Azure de Aplicações torna a
está ativado na App app mais segura
de Função eliminando segredos
de ligação. Ao
registar-se com o
no serviço de
serviços Azure de
forma segura, sem a
necessidade de nome
de utilizador e
palavras-passe.

Azure Ative Directory de Aplicações torna a
está ativado na Web app mais segura
App eliminando segredos
de ligação. Ao
registar-se com o
no serviço de
serviços Azure de
forma segura, sem a
necessidade de nome
de utilizador e
palavras-passe.

aplicação WEB tem cliente permitem que
"Certificados de a app solicite um
Cliente (Certificados certificado para
de cliente incoming)" pedidos de entrada.
definidos para 'On' Apenas os clientes
que tenham um
certificado válido
poderão chegar à
aplicação.
FTPS só deve ser Permitir a aplicação AuditIfNotExists, 1.0.0 Ligação

exigido na sua App do FTPS para uma Desativado
API maior segurança
FTPS só deve ser Permitir a aplicação AuditIfNotExists, 1.0.0 Ligação

exigido na sua App de do FTPS para uma Desativado
Função maior segurança
FTPS deve ser Permitir a aplicação AuditIfNotExists, 1.0.0 Ligação

necessário na sua do FTPS para uma Desativado
Web App maior segurança
A App de função só A utilização do HTTPS Auditoria, Deficientes 1.0.0 Ligação

deve estar acessível garante a
através do HTTPS autenticação do
servidor/serviço e
protege os dados em
trânsito contra
camadas de rede.
A versão TLS mais Upgrade para a AuditIfNotExists, 1.0.0 Ligação

recente deve ser versão mais recente Desativado
usada na sua App API do TLS
A versão TLS mais Upgrade para a AuditIfNotExists, 1.0.0 Ligação

recente deve ser versão mais recente Desativado
usada na sua App de do TLS
Função
A versão mais recente Upgrade para a AuditIfNotExists, 1.0.0 Ligação

do TLS deve ser usada versão mais recente Desativado
na sua Web App do TLS
A identidade gerida Utilize uma identidade AuditIfNotExists, 1.0.0 Ligação

deve ser usada na sua gerida para uma Desativado
App API segurança de
autenticação
reforçada

App de Função segurança de
autenticação
reforçada

Web App segurança de
autenticação
reforçada
Depuragem remota A depuragem remota AuditIfNotExists, 1.0.0 Ligação

deve ser desligada requer a abertura de Desativado
para apps da API portas de entrada em
aplicações API. A
depuragem remota
deve ser desligada.

deve ser desligada requer que as portas Desativado
para apps de funções de entrada sejam
abertas em aplicações
de função. A
depuragem remota
deve ser desligada.

deve ser desligada requer que as portas Desativado
para aplicações web de entrada sejam
abertas numa
aplicação web. A
depuragem remota
deve ser desligada.
A Aplicação Web só A utilização do HTTPS Auditoria, Deficientes 1.0.0 Ligação

deve ser acessível em garante a
HTTPS autenticação do
servidor/serviço e
protege os dados em
trânsito contra
camadas de rede.
Passos seguintes
Veja as incorporações no repositório do GitHub do Azure Policy.
Reveja a estrutura de definição do Azure Policy.
Veja Compreender os efeitos do Policy.
Descrição Geral do plano do Serviço de
Aplicações do Azure
No Serviço de Aplicações, as aplicações são executadas num plano do Serviço de Aplicações. Um plano do
Serviço de Aplicações define um conjunto de recursos de computação para a execução da aplicação Web.
Estes recursos computacionais são análogos à exploração de servidores em hospedagem web convencional.
Uma ou mais aplicações podem ser configuradas para executar os mesmos recursos de computação (ou no
mesmo plano de Serviço de Aplicações).
Quando se cria um plano de Serviço de Aplicações numa determinada região (por exemplo, na Europa
Ocidental), é criado um conjunto de recursos computacionais para esse plano naquela região. Quaisquer
aplicações que você colocou neste plano de App Service executado nestes recursos computacionais como
definido pelo seu plano de Serviço de Aplicações. Cada Plano do Serviço de Aplicações define o seguinte:
Região (E.U.A. Oeste, E.U.A. Leste, etc.)
Número de instâncias de VM
Tamanho das instâncias de VM (pequena, média, grande)
Nível de preços (Grátis, Partilhado, Básico, Standard, Premium, PremiumV2, Isolado)
O nível de preços de um plano de Serviço de Aplicações determina quais as funcionalidades do App Service
que obtém e quanto paga pelo plano. Existem algumas categorias de escalões de preço:
Computação par tilhada : Grátis e Par tilhados , os dois níveis base, executa uma aplicação no mesmo
Azure VM que outras aplicações do App Service, incluindo apps de outros clientes. Estes escalões alocam
quotas de CPU a cada uma das aplicações que executam nos recursos partilhados e os recursos não
podem ser aumentados horizontalmente.
Computação dedicada : Os níveis Basic , Standard, Premium e PremiumV2 executam aplicações em
VMs Azure dedicados. Apenas as aplicações no mesmo plano do Serviço de Aplicações partilham os
mesmos recursos de computação. Quanto maior for o escalão, mais instâncias de VM estarão disponíveis
para escalamento horizontal.
Isolado : Este nível executa VMs Azure dedicados em redes virtuais azure dedicadas. Fornece isolamento
de rede em cima do isolamento computacional para as suas apps. Fornece as capacidades máximas de
escalamento horizontal.
NOTE
Cada nível também fornece um subconjunto específico de funcionalidades do Serviço de Aplicações. Estas
funcionalidades incluem domínios personalizados e certificados TLS/SSL, autoscalcificação, slots de
implementação, backups, integração do Gestor de Tráfego e muito mais. Quanto maior for o nível, mais
funcionalidades estão disponíveis. Para saber quais as funcionalidades suportadas em cada nível de preços,
consulte os detalhes do plano do App Service.
NOTE
O novo nível de preços PremiumV2 fornece VMs da série Dv2 com processadores mais rápidos, armazenamento SSD
e dupla relação memória-núcleo em comparação com o nível Standard. PremiumV2 também suporta maior escala
através do aumento da contagem de instâncias, ao mesmo tempo que fornece todas as capacidades avançadas
encontradas no plano Standard. Todas as funcionalidades disponíveis no nível Premium existente estão incluídas no
PremiumV2 .
Semelhante a outros níveis dedicados, estão disponíveis três tamanhos VM para este nível:
Pequeno (um núcleo CPU, 3,5 GiB de memória)
Médio (dois núcleos CPU, 7 GiB de memória)
Grande (quatro núcleos cpu, 14 GiB de memória)
Para obter informações sobre preços PremiumV2, consulte preços de serviço de aplicação.
Para começar com o novo nível de preços PremiumV2, consulte configure PremiumV2 tier for App Service.
Como funciona a minha aplicação?

Nos níveis Free and Shared, uma aplicação recebe minutos de CPU numa instância de VM partilhada e não
pode escalar. Em outros níveis, uma aplicação corre e escala da seguinte forma.
Quando cria uma aplicação no App Service, é colocada num plano de Serviço de Aplicações. Quando a
aplicação funciona, funciona em todas as instâncias VM configuradas no plano de Serviço de Aplicações. Se
várias aplicações estiverem no mesmo plano de Serviço de Aplicações, todas partilham as mesmas instâncias
VM. Se tiver várias ranhuras de implementação para uma aplicação, todas as ranhuras de implementação
também funcionam nas mesmas instâncias VM. Se ativar registos de diagnóstico, executar backups ou
executar WebJobs, também utilizam ciclos de CPU e memória nestas instâncias VM.
Desta forma, o plano de Serviço de Aplicações é a unidade de escala das aplicações do App Service. Se o
plano estiver configurado para executar cinco instâncias VM, então todas as aplicações do plano funcionam
em todas as cinco instâncias. Se o plano estiver configurado para autodimensionamento, então todas as
aplicações do plano são dimensionadas em conjunto com base nas definições de escala automática.
Para obter informações sobre a escala de uma aplicação, consulte a contagem de exemplos scale
manualmente ou automaticamente.
Quanto custa o meu plano de Serviço de Aplicações?

Esta secção descreve como as aplicações do App Service são faturadas. Para obter informações detalhadas e
específicas sobre preços, consulte os preços do serviço de aplicações.
Com exceção do free tier, um plano de Serviço de Aplicações transporta uma carga horária sobre os recursos
computacionais que utiliza.
No nível Par tilhado, cada aplicação recebe uma quota de minutos cpu, pelo que cada aplicação é cobrada
de hora em hora para a quota CPU.
Nos níveis de cálculo dedicados (Basic, Standard, Premium, PremiumV2 ), o plano de Serviço de
Aplicações define o número de casos vm a que as aplicações são dimensionadas, pelo que cada instância
VM no plano de Serviço de Aplicações tem uma carga horária. Estes casos de VM são cobrados da mesma
forma, independentemente do número de aplicações que estão a ser em execução. Para evitar cargas
inesperadas, consulte A Limpeza de um plano de Serviço de Aplicações.
No nível Isolado, o Ambiente de Serviço de Aplicações define o número de trabalhadores isolados que
executam as suas apps, e cada trabalhador é cobrado de hora em hora. Além disso, há uma taxa base de
hora em hora para a execução do próprio App Service Environment.
Não é cobrado por utilizar as funcionalidades do Serviço de Aplicações que estão disponíveis para si
(configurar domínios personalizados, certificados TLS/SSL, slots de implementação, backups, etc.). As
exceções são:
Domínios de Serviço de Aplicações - paga-se quando compra um em Azure e quando o renova todos os
anos.
Certificados de Serviço de Aplicações - paga-se quando compra um em Azure e quando o renova todos os
anos.
Ligações TLS baseadas em IP - Há uma taxa horária para cada ligação TLS baseada em IP, mas algum nível
Standard ou acima dá-lhe uma ligação TLS baseada em IP gratuitamente. As ligações TLS baseadas em
SNI são gratuitas.
NOTE
Se integrar o Serviço de Aplicações com outro serviço Azure, poderá ter de considerar os encargos destes outros
serviços. Por exemplo, se utilizar o Gestor de Tráfego Azure para escalar a sua aplicação geograficamente, o Azure Traffic
Manager também o cobra com base no seu uso. Para estimar o seu custo de serviços transversais em Azure, consulte a
calculadora de preços.
E se a minha aplicação precisar de mais capacidades ou

funcionalidades?
O seu plano do Serviço de Aplicações pode ser aumentado e reduzido verticalmente em qualquer altura. É tão
simples como alterar o nível de preços do plano. Pode escolher um escalão de preço mais baixo inicialmente e
aumentar verticalmente mais tarde quando precisar de mais funcionalidades do Serviço de Aplicações.
Por exemplo, pode começar a testar a sua aplicação web num plano de Serviço de Aplicações Gratuito e não
pagar nada. Quando quiser adicionar o seu nome DNS personalizado à aplicação web, basta escalar o seu
plano até ao nível De par tilha. Mais tarde, quando quiser criar uma ligação TLS,escale o seu plano até ao
nível Básico. Quando quiser ter ambientes de encenação,escale até o nível Standard. Quando você precisa
de mais núcleos, memória ou armazenamento, escala até um tamanho VM maior no mesmo nível.
O mesmo funciona ao contrário. Quando sente que já não precisa das capacidades ou características de um
nível mais alto, pode descer para um nível mais baixo, o que poupa dinheiro.
Para obter informações sobre a ampliação do plano de serviço de aplicações, consulte scale up uma app em
Azure.
Se a sua aplicação estiver no mesmo plano de App Service com outras aplicações, poderá querer melhorar o
desempenho da aplicação isolando os recursos da computação. Pode fazê-lo movendo a aplicação para um
plano de Serviço de Aplicações separado. Para mais informações, consulte Mover uma aplicação para outro
plano de Serviço de Aplicações.
Devo colocar uma aplicação num novo plano ou num plano

existente?
Uma vez que paga os recursos de computação que o seu plano de Serviço de Aplicações atribui (ver quanto
custa o meu plano de Serviço de Aplicações? Pode continuar a adicionar apps a um plano existente, desde que
o plano tenha recursos suficientes para lidar com a carga. No entanto, tenha em mente que as aplicações no
mesmo plano de App Service partilham todos os mesmos recursos computacionais. Para determinar se a
nova aplicação tem os recursos necessários, terá de compreender a capacidade do plano do Serviço de
Aplicações existente e a carga esperada para a nova aplicação. Sobrecarregar um plano do Serviço de
Aplicações pode, potencialmente, levar a períodos de indisponibilidade para as suas aplicações novas e
existentes.
Isole a sua aplicação num novo plano do Serviço de Aplicações quando:
A aplicação é intensiva em recursos.
Deseja escalar a aplicação de forma independente das outras aplicações do plano existente.
A aplicação precisa de recursos numa região geográfica diferente.
Desta forma, pode alocar um novo conjunto de recursos para a sua app e ganhar um maior controlo das suas
apps.
Gerir um plano de serviço de aplicações

Gerir um plano de serviço de aplicações
Funcionalidade do sistema operativo no Serviço de
Aplicações Azure
Este artigo descreve a funcionalidade comum do sistema operativo de base que está disponível para todas as
aplicações do Windows que funcionam no Serviço de Aplicações Azure. Esta funcionalidade inclui acesso a
ficheiros, rede e registo, e registos e eventos de diagnóstico.
NOTE
As aplicações Linux no App Service funcionam nos seus próprios contentores. Não é permitido o acesso ao sistema
operativo do hospedeiro, tem acesso à raiz do recipiente. Da mesma forma, para aplicações em execução em contentores
Windows,tem acesso administrativo ao contentor, mas não tem acesso ao sistema operativo anfitrião.
Níveis de plano de aplicativos

O App Service executa aplicações de clientes num ambiente de hospedagem multi-inquilino. As aplicações
implementadas nos níveis Free e Shared funcionam em processos de trabalhador estoireiro em máquinas
virtuais partilhadas, enquanto as aplicações implementadas nos níveis Standard e Premium funcionam em
máquinas virtuais dedicadas especificamente às aplicações associadas a um único cliente.
NOTE
Uma vez que o App Service suporta uma experiência de escala perfeita entre diferentes níveis, a configuração de
segurança aplicada para aplicações do App Service continua a ser a mesma. Isto garante que as aplicações não se
comportam de forma diferente, falhando de formainesperada, quando o plano do App Service muda de um nível
para outro.
Quadros de desenvolvimento
Os níveis de preços do Serviço de Aplicações controlam a quantidade de recursos computacionais (CPU,
armazenamento de discos, memória e saída de rede) disponíveis para apps. No entanto, a amplitude da
funcionalidade-quadro disponível para as aplicações continua a ser a mesma, independentemente dos níveis de
escala.
O App Service suporta uma variedade de estruturas de desenvolvimento, incluindo ASP.NET, asas clássicas,
node.js, PHP e Python - todos os quais funcionam como extensões dentro do IIS. De forma a simplificar e
normalizar a configuração de segurança, as aplicações do App Service normalmente executam os vários quadros
de desenvolvimento com as suas definições padrão. Uma abordagem para configurar aplicações poderia ter sido
personalizar a área de superfície da API e a funcionalidade para cada quadro de desenvolvimento individual. Em
vez disso, o App Service tem uma abordagem mais genérica, permitindo uma linha de base comum da
funcionalidade do sistema operativo, independentemente do quadro de desenvolvimento de uma aplicação.
As seguintes secções resumem os tipos gerais de funcionalidade do sistema operativo disponíveis para aplicações
do App Service.
Acesso a ficheiros
Existem várias unidades dentro do Serviço de Aplicações, incluindo unidades locais e unidades de rede.
Unidades locais
No seu cerne, o App Service é um serviço que funciona em cima da infraestrutura Azure PaaS (plataforma como
serviço). Como resultado, as unidades locais que estão "ligadas" a uma máquina virtual são os mesmos tipos de
unidade disponíveis para qualquer função de trabalhador que esteja em funcionamento em Azure. Isto inclui:
Uma unidade do sistema operativo (o D:\ unidade)
Uma unidade de aplicação que contém ficheiros Azure Package cspkg utilizados exclusivamente pelo App
Service (e inacessíveis aos clientes)
Uma unidade "utilizador" (o C:\ unidade), cujo tamanho varia dependendo do tamanho do VM.
É importante monitorizar a utilização do disco à medida que a sua aplicação cresce. Se a quota do disco for
atingida, pode ter efeitos adversos na sua aplicação. Por exemplo:
A aplicação pode lançar um erro indicando que não há espaço suficiente no disco.
Pode ver erros no disco ao navegar na consola Kudu.
A implantação de Azure DevOps
ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk) ou
Visual Studio pode falhar com .
A sua aplicação pode sofrer um desempenho lento.
Unidades de rede (também conhecidas como ações da CNU )
Um dos aspetos únicos do App Service que torna a implementação e manutenção de aplicações simples é que
todos os conteúdos dos utilizadores são armazenados num conjunto de ações da UNC. Este modelo mapeia bem
o padrão comum de armazenamento de conteúdo usado por ambientes de hospedagem web no local que têm
múltiplos servidores equilibrados em carga.
Dentro do Serviço de Aplicações, há uma série de ações da UNC criadas em cada centro de dados. Uma
percentagem do conteúdo do utilizador para todos os clientes em cada centro de dados é atribuída a cada ação da
CNU. Além disso, todos os conteúdos de ficheiros para a subscrição de um único cliente são sempre colocados na
mesma parte da CNU.
Devido ao funcionar dos serviços azure, a máquina virtual específica responsável pelo alojamento de uma parte
da CNU mudará ao longo do tempo. É garantido que as ações da CNU serão montadas por diferentes máquinas
virtuais, uma vez que são trazidas para cima e para baixo durante o curso normal das operações do Azure. Por
esta razão, as aplicações nunca devem fazer pressupostos codificados de que a informação da máquina num
caminho de ficheiro sem fim permanecerá estável ao longo do tempo. Em vez disso, devem usar o conveniente
caminho absoluto d:\home\site que o Serviço de Aplicações fornece. Este caminho absoluto falso fornece um
método portátil, app-e-user-agnóstico para se referir à própria app. Ao utilizar o D:\home\site, pode-se
transferir ficheiros partilhados de app para app sem ter de configurar um novo caminho absoluto para cada
transferência.
Tipos de acesso a ficheiros concedidos a uma app
A subscrição de cada cliente tem uma estrutura de diretório reservada numa participação específica da UNC
dentro de um centro de dados. Um cliente pode ter várias aplicações criadas dentro de um centro de dados
específico, pelo que todos os diretórios pertencentes a uma única subscrição de cliente são criados na mesma
quota da CNU. A parte pode incluir diretórios como os de registos de conteúdo, erro e diagnóstico, e versões
anteriores da app criada pelo controlo de fontes. Como seria de esperar, os diretórios de aplicações de um cliente
estão disponíveis para leitura e acesso de escrita em tempo de execução pelo código de aplicação da aplicação da
aplicação.
Nas unidades locais anexadas à máquina virtual que executa uma app, o App Service reserva um pedaço de
espaço no C:\ unidade para armazenamento local temporário específico de aplicativo. Embora uma aplicação
tenha acesso completo ao seu próprio armazenamento local temporário, esse armazenamento não se destina a
ser utilizado diretamente pelo código de aplicação. Pelo contrário, a intenção é fornecer armazenamento
temporário de ficheiros para quadros de iis e aplicações web. O Serviço de Aplicações também limita a
quantidade de armazenamento local temporário disponível para cada aplicação para evitar que as aplicações
individuais consumam quantidades excessivas de armazenamento de ficheiros locais.
Dois exemplos de como o Serviço de Aplicações utiliza armazenamento local temporário são o diretório para
ficheiros de ASP.NET temporários e o diretório para ficheiros comprimidos IIS. O sistema de compilação ASP.NET
utiliza o diretório "Ficheiros de ASP.NET Temporários" como localização temporária de cache de compilação. O IIS
utiliza o diretório "IIS Temporary ComprimE Files" para armazenar a saída de resposta comprimido. Ambos os
tipos de utilização de ficheiros (assim como outros) são remapeados no Serviço de Aplicações para
armazenamento local temporário por app. Este remapping garante que a funcionalidade continua como esperado.
Cada aplicação no App Service funciona como uma identidade de processo de trabalho de
https://www.iis.net/learn/manage/configuring-security/application-pool-identitiesbaixo privilégio aleatório
chamada "identidade de piscina de aplicações", descrita aqui: . O código de aplicação utiliza esta identidade para o
acesso básico apenas à unidade do sistema operativo (o D:\ unidade). Isto significa que o código de aplicação
pode listar estruturas comuns de diretório e ler ficheiros comuns sobre a unidade do sistema operativo. Embora
este possa parecer um nível de acesso um pouco amplo, os mesmos diretórios e ficheiros são acessíveis quando
você presta um papel de trabalhador em um serviço hospedado Azure e lê o conteúdo da unidade.
Acesso de ficheiros em várias instâncias
O diretório doméstico contém o conteúdo de uma aplicação, e o código de aplicação pode escrever-lhe. Se uma
aplicação for executado em várias instâncias, o diretório doméstico é partilhado entre todos os casos para que
todos os casos vejam o mesmo diretório. Assim, por exemplo, se uma aplicação guardar ficheiros carregados para
o diretório inicial, esses ficheiros estão imediatamente disponíveis para todas as instâncias.
Acesso à rede
O código de aplicação pode utilizar protocolos baseados em TCP/IP e UDP para efelo ligações de rede de saída a
pontos finais acessíveis à Internet que expõem serviços externos. As aplicações podem utilizar estes mesmos
protocolos para se conectarem a serviços dentro do Azure, por exemplo, estabelecendo ligações HTTPS à Base de
Dados SQL.
Existe também uma capacidade limitada para as apps estabelecerem uma ligação de loopback local, e ter uma app
a ouvir naquela tomada de loopback local. Esta funcionalidade existe principalmente para permitir aplicações que
ouvem as tomadas de loopback locais como parte da sua funcionalidade. Cada aplicação vê uma ligação
"privada". A aplicação "A" não pode ouvir uma tomada de loopback local estabelecida pela app "B".
Os tubos nomeados também são suportados como um mecanismo de comunicação inter-processo (IPC) entre
diferentes processos que executam coletivamente uma app. Por exemplo, o módulo IIS FastCGI baseia-se em
tubos nomeados para coordenar os processos individuais que executam páginas PHP.
Execução de código, processos e memória

Como notado anteriormente, as aplicações funcionam dentro de processos de trabalhadores de baixo privilégio
usando uma identidade de piscina de aplicação aleatória. O código de aplicação tem acesso ao espaço de
memória associado ao processo do trabalhador, bem como a quaisquer processos infantis que possam ser
gerados por processos CGI ou outras aplicações. No entanto, uma aplicação não pode aceder à memória ou dados
de outra aplicação mesmo que esteja na mesma máquina virtual.
As aplicações podem executar scripts ou páginas escritas com quadros de desenvolvimento web suportados. O
Serviço de Aplicações não configura quaisquer definições de enquadramento web para modos mais restritos. Por
exemplo, ASP.NET aplicações que funcionam no App Service funcionam em "plena" confiança em oposição a um
modo de confiança mais restrito. As estruturas web, incluindo as asp clássicas e ASP.NET, podem ligar para
componentes com (mas não fora dos componentes com do processo) como o ADO (ActiveX Data Objects) que
são registados por padrão no sistema operativo Windows.
As aplicações podem desovar e executar código arbitrário. É permitido que uma aplicação faça coisas como gerar
uma concha de comando ou executar um script PowerShell. No entanto, embora códigos e processos arbitrários
possam ser gerados a partir de uma app, os programas e scripts executáveis ainda estão restritos aos privilégios
concedidos ao conjunto de aplicações dos pais. Por exemplo, uma aplicação pode gerar um executável que faz
uma chamada http de saída, mas esse mesmo executável não pode tentar desvincular o endereço IP de uma
máquina virtual do seu NIC. Fazer uma chamada de rede de saída é permitido a um código de baixo privilégio,
mas tentar reconfigurar as definições de rede numa máquina virtual requer privilégios administrativos.
Registos e eventos de diagnóstico

A informação de log é outro conjunto de dados que algumas apps tentam aceder. Os tipos de informação de
registo disponíveis para o código que funciona no App Service incluem informações de diagnóstico e registo
geradas por uma aplicação que também é facilmente acessível à aplicação.
Por exemplo, os registos W3C HTTP gerados por uma aplicação ativa estão disponíveis num diretório de registo
na localização da partilha de rede criada para a app, ou disponíveis no armazenamento blob se um cliente tiver
configurado o registo w3C para armazenamento. Esta última opção permite recolher grandes quantidades de
troncos sem o risco de exceder os limites de armazenamento de ficheiros associados a uma parte da rede.
Na mesma linha, as informações de diagnóstico em tempo real das aplicações .NET também podem ser registadas
utilizando a infraestrutura de rastreio e diagnóstico .NET, com opções para escrever as informações de rastreio
para a partilha de rede da aplicação, ou, em alternativa, para um local de armazenamento blob.
As áreas de registo de diagnósticos e rastreios que não estão disponíveis para apps são eventos Windows ETW e
registos comuns de eventos windows (por exemplo, registos de eventos system, application e segurança). Uma
vez que as informações sobre vestígios de ETW podem potencialmente ser visível em toda a máquina (com os
ACLs certos), ler e escrever o acesso aos eventos DeTW está bloqueado. Os desenvolvedores podem notar que as
chamadas da API para ler e escrever eventos ETW e registos comuns de eventos windows parecem funcionar, mas
isso porque o Serviço de Aplicações está a "fingir" as chamadas para que pareçam ter sucesso. Na realidade, o
código de aplicação não tem acesso aos dados deste evento.
Acesso ao registo
As aplicações têm acesso apenas a muito (embora não a toda) do registo da máquina virtual em que estão a
funcionar. Na prática, isto significa que as chaves de registo que permitem o acesso apenas a leitura ao grupo de
Utilizadores locais são acessíveis por apps. Uma área do registo que não é suportada atualmente para ler__ou
escrever acesso é a colmeia HKEY CURRENT USER.
O acesso por escrito ao registo está bloqueado, incluindo o acesso a quaisquer chaves de registo por utilizador. Do
ponto de vista da aplicação, o acesso ao registo nunca deve ser invocado no ambiente Azure, uma vez que as
aplicações podem (e fazem) ser migradas através de diferentes máquinas virtuais. O único armazenamento
recedível persistente que pode ser dependente de uma aplicação é a estrutura de diretório de conteúdos por app
armazenada nas ações da App Service UNC.
Acesso remoto ao ambiente de trabalho

O Serviço de Aplicações não fornece acesso remoto aos casos vm.
Mais informações
Caixa de areia azure App Service - As informações mais atualizadas sobre o ambiente de execução do Serviço de
Aplicações. Esta página é mantida diretamente pela equipa de desenvolvimento do Serviço de Aplicações.
Implementação de Boas Práticas
Todas as equipas de desenvolvimento têm requisitos únicos que podem dificultar a implementação de um pipeline de implantação eficiente em qualquer serviço na nuvem.
Este artigo introduz os três principais componentes da implantação para o Serviço de Aplicações: fontes de implantação, oleodutos de construção e mecanismos de
implantação. Este artigo também abrange algumas boas práticas e dicas para pilhas de idiomas específicas.
Componentes de implantação
Fonte de Implantação
Uma fonte de implantação é a localização do seu código de aplicação. Para aplicações de produção, a fonte de implantação é geralmente um repositório hospedado por
software de controlo de versão como GitHub, BitBucket ou Azure Repos. Para cenários de desenvolvimento e teste, a fonte de implantação pode ser um projeto na sua
máquina local. O Serviço de Aplicações também suporta as pastas OneDrive e Dropbox como fontes de implementação. Embora as pastas de nuvem possam facilitar o início
com o App Service, não é tipicamente recomendado utilizar esta fonte para aplicações de produção a nível empresarial.
Pipeline de Compilação
Assim que decidires sobre uma fonte de implantação, o teu próximo passo é escolher um oleoduto de construção. Um pipeline de construção lê o seu código fonte a partir da
fonte de implementação e executa uma série de passos (como a compilação de código, minificação HTML e JavaScript, testes de execução e componentes de embalagem) para
obter a aplicação em estado de execução. Os comandos específicos executados pelo oleoduto dependem da sua pilha de linguagem. Estas operações podem ser executadas
num servidor de construção, como o Azure Pipelines, ou executadas localmente.
Mecanismo de Implantação
O mecanismo de implementação é a ação usada para colocar a sua aplicação incorporada no diretório /home/site/wwwroot da sua aplicação web. O diretório /wwwroot é um
local de armazenamento montado partilhado por todos os casos da sua aplicação web. Quando o mecanismo de implementação coloca a sua aplicação neste diretório, os
seus casos recebem uma notificação para sincronizar os novos ficheiros. O Serviço de Aplicações suporta os seguintes mecanismos de implementação:
Pontos finais kudu: Kudu é a ferramenta de produtividade de desenvolvedores de código aberto que funciona como um processo separado no Serviço de Aplicações
Windows, e como um segundo recipiente no Serviço de Aplicações Linux. Kudu lida com implementações contínuas e fornece pontos finais HTTP para implantação, como
zipdeploy.
FTP e WebDeploy: Utilizando as credenciais do seu site ou utilizador,pode carregar ficheiros via FTP ou WebDeploy. Estes mecanismos não passam por Kudu.
Ferramentas de implantação como pipelines Azure, Jenkins e plugins editor usam um destes mecanismos de implementação.
Utilizar ranhuras de implantação

Sempre que possível, utilize ranhuras de implantação ao implementar uma nova construção de produção. Ao utilizar um nível padrão de plano de aplicação ou melhor, pode
implementar a sua aplicação para um ambiente de encenação, validar as suas alterações e fazer testes de fumo. Quando estiver pronto, pode trocar as suas faixas horárias de
preparação e produção. A operação de troca aquece as instâncias de trabalho necessárias para corresponder à sua escala de produção, eliminando assim o tempo de
inatividade.
Código de implantação contínua
Se o seu projeto designou ramos para testes, QA e encenação, então cada um desses ramos deve ser continuamente implantado para uma ranhura de encenação. (Isto é
conhecido como o design Gitflow.) Isto permite que as suas partes interessadas avaliem e testem facilmente o ramo implantado.
A implantação contínua nunca deve ser ativada para a sua ranhura de produção. Em vez disso, o seu ramo de produção (muitas vezes mestre) deve ser implantado numa
ranhura de não produção. Quando estiver pronto para libertar o ramo base, troque-o na ranhura de produção. A troca em produção — em vez de se implantar na produção
— evita o tempo de inatividade e permite-lhe reverter as alterações trocando novamente.
Implantar continuamente contentores

Para recipientes personalizados do Docker ou outros registos de contentores, desloque a imagem para uma ranhura de preparação e troque em produção para evitar o tempo
de inatividade. A automatização é mais complexa do que a implementação de código, pois deve empurrar a imagem para um registo de contentores e atualizar a etiqueta de
imagem na webapp.
Para cada ramo que pretende implantar para uma ranhura, instale a automatização para fazer o seguinte em cada compromisso com o ramo.
1. Construa e marque a imagem. Como parte do pipeline de construção, marque a imagem com o git commit ID, timestamp ou outra informação identificável. É melhor
não usar a etiqueta "mais recente" padrão. Caso contrário, é difícil rastrear o código atualmente implementado, o que torna a depuração muito mais difícil.
2. Empurre a imagem marcada. Uma vez que a imagem é construída e marcada, o gasoduto empurra a imagem para o nosso registo de contentores. No próximo passo, a
ranhura de implantação retirará a imagem marcada do registo do contentor.
3. Atualize a ranhura de implementação com a nova etiqueta de imagem . Quando esta propriedade for atualizada, o site reiniciará automaticamente e puxará a nova
imagem do recipiente.
Há exemplos abaixo para quadros comuns de automação.

Use Azure DevOps
O Serviço de Aplicações tem entrega contínua incorporada para contentores através do Centro de Implantação. Navegue para a sua aplicação no portal Azure e selecione
Centro de Implantação sob Implantação . Siga as instruções para selecionar o seu repositório e o seu ramo. Isto configurará um oleoduto de construção e libertação de
DevOps para construir, etiquetar e implantar automaticamente o seu recipiente quando novos compromissos forem empurrados para o seu ramo selecionado.
Use ações gitHub
Também pode automatizar a implantação do seu contentor com ações GitHub. O ficheiro de fluxo de trabalho abaixo irá construir e etiquetar o recipiente com o ID de
compromisso, empurrá-lo para um registo de contentores e atualizar a ranhura especificada do site com a nova etiqueta de imagem.
name: Build and deploy a container image to Azure Web Apps
on:
push:
branches:
- <your-branch-name>
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
-name: Authenticate using a Service Principal

uses: azure/actions/login@v1
with:
creds: ${{ secrets.AZURE_SP }}
- uses: azure/container-actions/docker-login@v1
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
- name: Build and push the image tagged with the git commit hash
run: |
docker build . -t contoso/demo:${{ github.sha }}
docker push contoso/demo:${{ github.sha }}
- name: Update image tag on the Azure Web App

uses: azure/webapps-container-deploy@v1
with:
app-name: '<your-webapp-name>'
slot-name: '<your-slot-name>'
images: 'contoso/demo:${{ github.sha }}'
Utilizar outros fornecedores de automação

As etapas anteriormente enumeradas aplicam-se a outros utilitários de automação, como o CircleCI ou o Travis CI. No entanto, é necessário utilizar o Azure CLI para atualizar
as ranhuras de implementação com novas etiquetas de imagem no passo final. Para utilizar o Azure CLI no seu script de automação, gere um Diretor de Serviço utilizando o
seguinte comando.
az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \

--scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
--sdk-auth
No seu script, az login --service-principal faça login na utilização, fornecendo as informações do diretor. Em seguida, az webapp config container set pode utilizar para
definir o nome do recipiente, etiqueta, URL de registo e senha de registo. Abaixo estão alguns links úteis para você construir o seu processo CI recipiente.
Como iniciar sessão no Azure CLI no Circle CI
Considerações específicas da linguagem

Java
Utilize o zipdeploy/API Kudu para a implementação de aplicações JAR e wardeploy/para aplicações WAR. Se estiver a usar o Jenkins, pode utilizar essas APIs diretamente na
sua fase de implantação. Para obter mais informações, consulte este artigo.
Nó
Por padrão, kudu executa os passos npm install de construção para a sua aplicação Nó (). Se está a usar um serviço de construção como o Azure DevOps, então a construção
de Kudu é desnecessária. Para desativar a construção kudu, crie uma definição de app, SCM_DO_BUILD_DURING_DEPLOYMENT com um valor de false .
.NET
Por padrão, kudu executa os passos dotnet build de construção para a sua aplicação .NET ( ). Se está a usar um serviço de construção como o Azure DevOps, então a
construção de Kudu é desnecessária. Para desativar a construção kudu, crie uma definição de app, SCM_DO_BUILD_DURING_DEPLOYMENT com um valor de false .
Outras considerações de implantação

Local Cache
O conteúdo do Serviço de Aplicações Azure é armazenado no Armazenamento Azure e é surgido de forma duradoura como partilha de conteúdo. No entanto, algumas
aplicações apenas precisam de uma loja de conteúdos de alto desempenho, apenas de leitura, que podem executar com elevada disponibilidade. Estas aplicações podem
beneficiar da utilização de cache local. A cache local não é recomendada para sites de gestão de conteúdos como o WordPress.
Utilize sempre a cache local em conjunto com as ranhuras de implantação para evitar o tempo de inatividade. Consulte esta secção para obter informações sobre a utilização
destas funcionalidades em conjunto.
Alta CPU ou Memória
Se o seu Plano de Serviço de Aplicações estiver a utilizar mais de 90% do CPU ou memória disponível, a máquina virtual subjacente pode ter problemas em processar a sua
implementação. Quando isto acontecer, aumenta temporariamente a contagem de casos para realizar a implantação. Uma vez terminada a implantação, pode devolver a
contagem de ocorrências ao seu valor anterior.
Para obter mais informações sobre as melhores práticas, visite o App Service Diagnostics para descobrir as melhores práticas atol específicas do seu recurso.
Navegue para a sua Web App no portal Azure.
Clique em Diagnosticar e resolver problemas na navegação à esquerda, o que abre diagnósticos de serviço de aplicações.
Escolha o azulejo da página inicial das Melhores Práticas.
Clique em Boas Práticas para Disponibilidade & Desempenho ou Boas Práticas para Uma Configuração Ideal para ver o estado atual da sua aplicação no que
diz respeito a estas boas práticas.
Também pode utilizar este link para abrir diretamente os
https://ms.portal.azure.com/?
websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Micr
Diagnósticos do Serviço de Aplicações para o seu recurso: .
Recomendações de segurança para o Serviço de
Aplicações
Este artigo contém recomendações de segurança para o Azure App Service. A implementação destas
recomendações irá ajudá-lo a cumprir as suas obrigações de segurança conforme descrito no nosso modelo de
responsabilidade partilhada e melhorará a segurança global das suas soluções web App. Para obter mais
informações sobre o que a Microsoft faz para cumprir as responsabilidades do prestador de serviços, leia a
segurança da infraestrutura azure.
Geral
REC O M EN DA Ç Ã O C O M EN TÁ RIO S
Mantenha-se atualizado Utilize as versões mais recentes de plataformas suportadas,

linguagens de programação, protocolos e quadros.
Gestão de identidades e acessos

Desativar o acesso anónimo A menos que precise apoiar pedidos anónimos, desative o
acesso anónimo. Para obter mais informações sobre as opções
de autenticação do Serviço de Aplicações Azure, consulte
autenticação e autorização no Serviço de Aplicações Azure.
Exigir autenticação Sempre que possível, utilize o módulo de autenticação do

Serviço de Aplicações em vez de escrever código para lidar
com a autenticação e autorização. Consulte a Autenticação e
autorização no Serviço de Aplicações Azure.
Proteja os recursos back-end com acesso autenticado Pode utilizar a identidade do utilizador ou utilizar uma
identidade de aplicação para autenticar um recurso de back-
end. Quando optar por utilizar uma identidade de aplicação,
utilize uma identidade gerida.
Exigir autenticação do certificado de cliente A autenticação do certificado de cliente melhora a segurança

permitindo apenas ligações de clientes que possam autenticar
usando certificados que fornece.
Proteção de dados
Redirecione http para HTTPs Por padrão, os clientes podem ligar-se a aplicações web
utilizando http ou HTTPS. Recomendamos redirecionar http
para HTTPs porque HTTPS utiliza o protocolo SSL/TLS para
fornecer uma ligação segura, que é encriptada e autenticada.
Encriptar a comunicação aos recursos do Azure Quando a sua aplicação se conecta aos recursos do Azure,
como a Base de Dados SQL ou o Armazenamento Azure,a
ligação permanece no Azure. Uma vez que a ligação passa pela
rede partilhada em Azure, deve sempre encriptar todas as
comunicações.
Requeiram a mais recente versão TLS possível Desde 2018 que as novas aplicações do Azure App Service
utilizam o TLS 1.2. Versões mais recentes de TLS incluem
melhorias de segurança em relação a versões de protocolo
mais antigas.
Utilizar FTPS O Serviço de Aplicações suporta ftp e FTPS para a

implementação dos seus ficheiros. Utilize ftps em vez de FTP
quando possível. Quando um ou ambos os protocolos não
estiverem a ser utilizados, deve desativá-los.
Proteger os dados das aplicações Não guarde segredos de aplicação, tais como credenciais de
base de dados, fichas API ou chaves privadas no seu código
ou ficheiros de configuração. A abordagem geralmente aceite
é acessá-las como variáveis ambientais usando o padrão
padrão na sua linguagem de eleição. No Serviço de Aplicações
Azure, pode definir variáveis ambientais através de
configurações de aplicações e cordas de ligação. As definições
de aplicativos e as cordas de ligação são armazenadas
encriptadas no Azure. As definições da aplicação só são
desencriptadas antes de serem injetadas na memória de
processo da sua aplicação quando a aplicação começar. As
chaves de encriptação são rodadas regularmente. Em
alternativa, pode integrar a sua aplicação Azure App Service
com o Azure Key Vault para uma gestão avançada de
segredos. Ao aceder ao Key Vault com uma identidade
gerida,a sua aplicação App Service pode aceder de forma
segura aos segredos de que necessita.
Redes
Utilize restrições ip estáticas O Serviço de Aplicações Azure no Windows permite definir

uma lista de endereços IP que estão autorizados a aceder à
sua aplicação. A lista permitida pode incluir endereços IP
individuais ou uma série de endereços IP definidos por uma
máscara de sub-rede. Para mais informações, consulte as
restrições de IP estáticas do Serviço de Aplicação Azure.
Utilize o nível de preços isolado Com exceção do nível de preços isolado, todos os níveis
executam as suas aplicações na infraestrutura de rede
partilhada no Serviço de Aplicações Azure. O nível isolado dá-
lhe o isolamento total da rede executando as suas aplicações
dentro de um ambiente dedicado ao Serviço de Aplicações.
Um ambiente de serviço de aplicações funciona no seu próprio
exemplo de Rede Virtual Azure.
Utilize ligações seguras ao aceder aos recursos no local Pode utilizar ligações Híbridas, integração de redes virtuaisou
ambiente de serviço de aplicação para se conectar aos
recursos no local.
Limitar a exposição ao tráfego da rede de entrada Os grupos de segurança da rede permitem-lhe restringir o
acesso à rede e controlar o número de pontos finais expostos.
Para mais informações, consulte Como Controlar o Tráfego de
Entrada para um Ambiente de Serviço de Aplicações.
Monitorização
Use o nível padrão do Azure Security Center O Azure Security Center está integrado de forma nativa com o
Azure App Service. Pode fazer avaliações e fornecer
recomendações de segurança.
Passos seguintes
Consulte o seu fornecedor de candidaturas para ver se existem requisitos de segurança adicionais. Para obter mais
informações sobre o desenvolvimento de aplicações seguras, consulte documentação de desenvolvimento seguro.
Autenticação e autorização no Serviço de
Aplicações Azure e Funções Azure
NOTE
Neste momento, ASP.NET Core não suporta atualmente a população do utilizador atual com a funcionalidade de
Autenticação/Autorização.
O Azure App Service fornece suporte de autenticação e autorização incorporado, para que possa inscrever os
utilizadores e aceder aos dados escrevendo o mínimo ou nenhum código na sua aplicação web, a API RESTful e
a traseira móvel, bem como as Funções Azure. Este artigo descreve como o Serviço de Aplicações ajuda a
simplificar a autenticação e a autorização para a sua aplicação.
A autenticação e a autorização seguras requerem uma compreensão profunda da segurança, incluindo a
federação, encriptação, gestão de tokens web JSON (JWT), tipos de subvenções,e assim por diante. O Serviço
de Aplicações fornece estes utilitários para que possa gastar mais tempo e energia em fornecer valor de
negócio ao seu cliente.
IMPORTANT
Não é obrigado a utilizar esta funcionalidade para autenticação e autorização. Pode utilizar as funcionalidades de
segurança agregadas no seu quadro web de eleição, ou pode escrever os seus próprios utilitários. No entanto, tenha em
mente que o Chrome 80 está a fazer alterações na sua implementação do SameSite para cookies (data de lançamento
em março de 2020), e a autenticação remota personalizada ou outros cenários que dependem da publicação de cookies
transsite podem quebrar quando os navegadores Chrome do cliente forem atualizados. A suticidade é complexa porque
precisa de suportar diferentes comportamentos do SameSite para diferentes navegadores.
As versões ASP.NET Core 2.1 e acima hospedadas pelo App Service já estão corrigidas para esta alteração de rutura e
manuseiem adequadamente o Chrome 80 e navegadores mais antigos. Além disso, o mesmo patch para ASP.NET
Quadro 4.7.2 está a ser implementado nos casos do Serviço de Aplicações ao longo de janeiro de 2020. Para mais
informações, incluindo como saber se a sua aplicação recebeu o patch, consulte a atualização de cookies do Mesmo Site
do Serviço de Aplicações Azure.
Para obter informações específicas para aplicações móveis nativas, consulte a autenticação do Utilizador e a
autorização para aplicações móveis com o Azure App Service.
Como funciona
O módulo de autenticação e autorização funciona na mesma caixa de areia que o seu código de aplicação.
Quando está ativado, todos os pedidos http que chegam passam por ele antes de serem tratados pelo seu
código de aplicação.
Este módulo lida com várias coisas para a sua aplicação:
Autentica os utilizadores com o fornecedor especificado
Valida, lojas e fichas refrescantes
Gere a sessão autenticada
Injeta informações de identidade em cabeçalhos de pedido
O módulo funciona separadamente do seu código de aplicação e é configurado utilizando as definições da
aplicação. Não são necessários SDKs, línguas específicas ou alterações ao código de aplicação.
Reclamações de utilizador/aplicação
Para todos os quadros linguísticos, o App Service disponibiliza as reclamações no token de entrada (seja de um
utilizador final autenticado ou de uma aplicação cliente) disponível para o seu código injetando-as nos
cabeçalhos de pedido. Para ASP.NET 4.6 aplicações, o Serviço de Aplicações povoa o ClaimsPrincipal.Current
com as alegações do utilizador autenticado, para que possa seguir o padrão de código .NET padrão, incluindo o
[Authorize] atributo. Da mesma forma, para aplicações PHP, o App Service povoa a _SERVER['REMOTE_USER']
variável. Para aplicações Java, as reclamações são acessíveis a partir do servlet Tomcat.
Para funções Azure, ClaimsPrincipal.Current não é povoado para o código .NET, mas ainda pode encontrar as
reclamações do utilizador nos cabeçalhos de pedido, ou obter o objeto do contexto de pedido ou mesmo
através de um parâmetro de ClaimsPrincipal ligação. Consulte trabalhar com as identidades dos clientes para
obter mais informações.
Para mais informações, consulte as reclamações dos utilizadoresdo Access.
Arquivo de tokens
O App Service fornece uma loja de token incorporada, que é um repositório de fichas que estão associadas aos
utilizadores das suas aplicações web, APIs ou aplicações móveis nativas. Quando ativa a autenticação com
qualquer fornecedor, esta loja token está imediatamente disponível para a sua aplicação. Se o seu código de
aplicação necessitar de aceder a dados destes fornecedores em nome do utilizador, tais como:
post para a linha temporal do Facebook do utilizador autenticado
ler os dados corporativos do utilizador usando a API do Microsoft Graph
Normalmente, tem de escrever código para recolher, armazenar e refrescar estes tokens na sua aplicação. Com
a loja de fichas, basta recuperar os tokens quando precisar e dizer ao Serviço de Aplicações para os refrescar
quando ficarem inválidos.
Os tokens id, tokens de acesso e tokens de atualização são cachepara a sessão autenticada, e são acessíveis
apenas pelo utilizador associado.
Se não precisar de trabalhar com fichas na sua aplicação, pode desativar a loja de fichas.
Exploração madeireira e rastreio
Se ativaro registo de pedidos, verá a autenticação e a autorização rastreia-os diretamente nos seus ficheiros de
registo. Se vir um erro de autenticação que não esperava, pode convenientemente encontrar todos os detalhes
olhando para os registos de aplicação existentes. Se ativar o rastreio de pedidos falhados,pode ver exatamente
qual o papel que o módulo de autenticação e autorização pode ter desempenhado num pedido falhado. Nos
registos de rastreio, procure referências a um módulo chamado EasyAuthModule_32/64 .
Fornecedores de identidade
O Serviço de Aplicações utiliza identidade federada, na qual um fornecedor de identidade de terceiros gere as
identidades dos utilizadores e o fluxo de autenticação para si. Cinco fornecedores de identidade estão
disponíveis por defeito:
F O RN EC EDO R P O N TO F IN A L DE IN SC RIÇ Ã O
Azure Active Directory /.auth/login/aad
Conta Microsoft /.auth/login/microsoftaccount
Facebook /.auth/login/facebook
Google /.auth/login/google
Twitter /.auth/login/twitter
Quando permite a autenticação e autorização com um destes fornecedores, o seu ponto final de sessão está
disponível para autenticação do utilizador e para validação de fichas de autenticação do fornecedor. Pode
fornecer aos seus utilizadores qualquer número destas opções de sessão com facilidade. Também pode
integrar outro fornecedor de identidade ou a sua própria solução de identidade personalizada.
Fluxo de autenticação
O fluxo de autenticação é o mesmo para todos os fornecedores, mas difere consoante pretenda iniciar sessão
com o SDK do fornecedor:
Sem o fornecedor SDK: Os delegados de aplicação federaram o serviço de aplicação. Este é normalmente o
caso das aplicações do navegador, que podem apresentar a página de login do fornecedor ao utilizador. O
código do servidor gere o processo de entrada, pelo que também é chamado de fluxo de servidor ou fluxo
de servidor. Este caso aplica-se às aplicações do navegador. Aplica-se também a aplicações nativas que
assinam utilizadores na utilização do cliente de Aplicações Móveis SDK porque o SDK abre uma visão web
para iniciar sessão com a autenticação do App Service.
Com o fornecedor SDK: A aplicação inscreve os utilizadores manualmente no fornecedor e, em seguida,
envia o símbolo de autenticação ao Serviço de Aplicações para validação. Este é normalmente o caso de
aplicações sem navegador, que não podem apresentar a página de entrada do fornecedor ao utilizador. O
código de aplicação gere o processo de entrada, pelo que também é chamado fluxo de clientes ou fluxo de
cliente. Este caso aplica-se aos clientes REST APIs, Azure Functionse JavaScript, bem como aplicações de
navegador que precisam de mais flexibilidade no processo de entrada. Aplica-se também a aplicações
móveis nativas que assinam os utilizadores na utilização do SDK do fornecedor.
NOTE
As chamadas de uma aplicação de navegador fidedigna no Serviço de Aplicações para outro Rest API no Serviço de
Aplicações ou Funções Azure podem ser autenticadas usando o fluxo direcionado para o servidor. Para mais informações,
consulte Personalizar a autenticação e autorização no Serviço de Aplicações.
A tabela abaixo mostra os passos do fluxo de autenticação.
PA SSO SEM P RO VEDO R SDK C O M O P RO VEDO R SDK
1. Iniciar sessão no utilizador Redireciona o cliente para O código do cliente assina o utilizador
/.auth/login/<provider> . diretamente com o SDK do fornecedor
e recebe um símbolo de autenticação.
Para obter informações, consulte a
documentação do fornecedor.
2. Pós-autenticação O fornecedor redireciona o cliente Os posts de código do cliente são

para token do fornecedor para
/.auth/login/<provider>/callback /.auth/login/<provider> a
. validação.
3. Estabelecer sessão autenticada O Serviço de Aplicações adiciona O Serviço de Aplicações devolve o seu
cookie autenticado à resposta. próprio símbolo de autenticação ao
código do cliente.
4. Servir conteúdo autenticado O cliente inclui cookie de autenticação O código do cliente apresenta token
em pedidos subsequentes (tratado de autenticação no X-ZUMO-AUTH
automaticamente pelo navegador). cabeçalho (tratado automaticamente
por SDKs clientes de Aplicações
Móveis).
Para os navegadores de clientes, o Serviço de Aplicações pode direcionar automaticamente todos os

utilizadores não autenticados para /.auth/login/<provider> . Também pode apresentar aos utilizadores uma
ou mais /.auth/login/<provider> links para iniciar sessão na sua aplicação utilizando o seu fornecedor de
eleição.
Comportamento de autorização
No portal Azure,pode configurar a autorização do Serviço de Aplicações com vários comportamentos quando
o pedido de entrada não é autenticado.
Os seguintes títulos descrevem as opções.

Permitir pedidos anónimos (sem ação )
Esta opção adia a autorização de tráfego não autenticado para o seu código de aplicação. Para pedidos
autenticados, o Serviço de Aplicações também passa informações de autenticação nos cabeçalhos HTTP.
Esta opção proporciona mais flexibilidade no tratamento de pedidos anónimos. Por exemplo, permite-lhe
apresentar vários fornecedores de sessão aos seus utilizadores. No entanto, tem de escrever código.
Permitir apenas pedidos autenticados
A opção é iniciar sessão com < o fornecedor> . O Serviço de Aplicações redireciona todos os pedidos
anónimos /.auth/login/<provider> para o fornecedor que escolher. Se o pedido anónimo vier de uma
aplicação móvel nativa, a resposta devolvida é HTTP 401 Unauthorized uma .
Com esta opção, não precisa de escrever qualquer código de autenticação na sua aplicação. A autorização mais
fina, como a autorização específica para o papel, pode ser tratada inspecionando as reclamações do utilizador
(ver Access user claims).
Cau t i on
Restringir o acesso desta forma aplica-se a todas as chamadas para a sua app, o que pode não ser desejável
para aplicações que pretendam uma página inicial publicamente disponível, como em muitas aplicações de
página única.
NOTE
A autenticação/autorização era anteriormente conhecida como Easy Auth.
Mais recursos
Tutorial: Autenticar e autorizar utilizadores de ponta a ponta no Serviço de Aplicações Azure (Windows)
Tutorial: Autenticar e autorizar utilizadores de ponta a ponta no Serviço de Aplicações Azure para linux
Personalizar a autenticação e autorização no Serviço de Aplicações .NET Integração core do Azure AppService
EasyAuth (3ª parte) Obtenção da autenticação do Serviço de Aplicações Azure a trabalhar com .NET Core (3ª
parte)
Guias específicos do fornecedor:
Como configurar a sua aplicação para utilizar o início de sessão do Azure Active Directory
Como configurar a sua aplicação para utilizar o início de sessão do Facebook
Como configurar a sua aplicação para utilizar o início de sessão do Google
Como configurar a sua aplicação para utilizar o início de sessão da conta Microsoft
Como configurar a sua aplicação para utilizar o início de sessão do Twitter
Como: Utilizar a autenticação personalizada para a sua aplicação
SO e patching de tempo de execução no Serviço de
Aplicações Azure
Este artigo mostra-lhe como obter certas informações de versão relativas ao SISTEMA ou software no App
Service.
O Serviço de Aplicações é um Serviço de Plataforma-as-a-Service, o que significa que o SISTEMA e a pilha de
aplicações são geridos para si pelo Azure; só gere a sua aplicação e os seus dados. Mais controlo sobre o SISTEMA
e a pilha de aplicações está disponível em Máquinas Virtuais Azure. Com isso em mente, é, no entanto, útil para si,
enquanto utilizador do App Service, saber mais informações, tais como:
Como e quando são aplicadas as atualizações do OS?
Como é que o Serviço de Aplicações é corrigido contra vulnerabilidades significativas (como o dia zero)?
Que versões DE E E o SISTEMA e o tempo de execução estão a executar as suas aplicações?
Por razões de segurança, certas especificidades das informações de segurança não são publicadas. No entanto, o
artigo visa aliviar as preocupações maximizando a transparência no processo e como pode manter-se atualizado
sobre anúncios relacionados com a segurança ou atualizações de tempo de funcionamento.
Como e quando são aplicadas as atualizações do OS?

O Azure gere a correção de OS em dois níveis, os servidores físicos e as máquinas virtuais dos hóspedes (VMs)
que executam os recursos do Serviço de Aplicações. Ambos são atualizados mensalmente, o que se alinha com o
horário mensal de terça-feira. Estas atualizações são aplicadas automaticamente, de forma a garantir a alta
disponibilidade de Serviços Azure.
Para obter informações detalhadas sobre como as atualizações são aplicadas, consulte desmistificar a magia por
trásdas atualizações do App Service OS .
Como é que o Azure lida com vulnerabilidades significativas?

Quando as vulnerabilidades severas requerem remendos imediatos, tais como vulnerabilidades de zero dias,as
atualizações de alta prioridade são tratadas caso a caso.
Mantenha-se atual com anúncios de segurança críticos em Azure visitando o Azure Security Blog.
Quando é que os tempos de execução da linguagem suportados são

atualizados, adicionados ou depreciados?
Novas versões estáveis de tempos de execução de idiomas suportados (grandes, menores ou patch) são
periodicamente adicionadas às instâncias do App Service. Algumas atualizações sobrepõem a instalação existente,
enquanto outras são instaladas lado a lado com as versões existentes. Uma instalação de sobreescrita significa que
a sua aplicação funciona automaticamente no tempo de execução atualizado. Uma instalação lado a lado significa
que deve migrar manualmente a sua aplicação para tirar partido de uma nova versão de tempo de
funcionamento. Para mais informações, consulte uma das subsecções.
Atualizações e depreciações de tempo de execução são anunciados aqui:
https://azure.microsoft.com/updates/?product=app-service
https://github.com/Azure/app-service-announcements/issues
NOTE
A informação aqui se aplica aos tempos de execução de idiomas que são incorporados numa aplicação do App Service. Um
tempo de funcionamento personalizado que você envia para o App Service, por exemplo, permanece inalterado a menos
que você atualize manualmente.
Novas atualizações de patch

As atualizações de patch para .NET, PHP, Java SDK ou tomcat/Jetty são aplicadas automaticamente,
sobrecarregando a instalação existente com a nova versão. As atualizações de patch node.js são instaladas lado a
lado com as versões existentes (semelhantes às versões principais e menores na secção seguinte). As novas
versões de patch Python podem ser instaladas manualmente através de extensões do local,lado a lado com as
instalações python incorporadas.
Novas versões principais e menores
Quando uma nova versão principal ou menor é adicionada, é instalada lado a lado com as versões existentes. Pode
atualizar manualmente a sua aplicação para a nova versão. Se configurar a versão tempo de execução web.config
package.json num ficheiro de configuração (por exemplo e), precisa de atualizar com o mesmo método. Se usou
uma definição do Serviço de Aplicações para configurar a sua versão de tempo de execução, pode trocá-la no
portal Azure ou executando um comando Azure CLI na Cloud Shell,como mostram os seguintes exemplos:
az webapp config set --net-framework-version v4.7 --resource-group <groupname> --name <appname>

az webapp config set --php-version 7.0 --resource-group <groupname> --name <appname>
az webapp config appsettings set --settings WEBSITE_NODE_DEFAULT_VERSION=8.9.3 --resource-group <groupname> --
name <appname>
az webapp config set --python-version 3.4 --resource-group <groupname> --name <appname>
az webapp config set --java-version 1.8 --java-container Tomcat --java-container-version 9.0 --resource-group
<groupname> --name <appname>
Versões depreciadas
Quando uma versão mais antiga é depreciada, a data de remoção é anunciada para que possa planear a
atualização da sua versão runtime em conformidade.
Como posso consultar o OS e o estado de atualização do tempo de

funcionar nas minhas instâncias?
Embora as informações críticas do OS estão bloqueadas a partir do acesso (ver Funcionalidade do sistema
operativo no Serviço de Aplicações Azure),a consola Kudu permite-lhe consultar a sua instância de Serviço de
Aplicações relativamente à versão OS e versões de tempo de execução.
A tabela que se segue mostra como é que as versões do Windows e do tempo de execução do idioma que estão a
executar as suas aplicações:
IN F O RM A Ç Õ ES O N DE EN C O N T RÁ - LO
Versão do Windows Ver

https://<appname>.scm.azurewebsites.net/Env.cshtml
(de acordo com informações do Sistema)
IN F O RM A Ç Õ ES O N DE EN C O N T RÁ - LO
versão .NET Em
https://<appname>.scm.azurewebsites.net/DebugConsole ,
executar o seguinte comando no pedido de comando:
powershell -command "gci
'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Net
Framework Setup\NDP\CDF'"
versão .NET Core Em

dotnet --version
Versão PHP Em
php --version
Versão Padrão Node.js Na Cloud Shell,executar o seguinte comando:

az webapp config appsettings list --resource-group
<groupname> --name <appname> --query "[?
name=='WEBSITE_NODE_DEFAULT_VERSION']"
Versão de Python Em
python --version
Versão Java Em
java -version
NOTE
O acesso à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages
localização do registo, onde as informações sobre os patches "KB" são armazenados, é bloqueado.
Mais recursos
Centro de Confiança: Segurança
64 bits ASP.NET Core no Serviço de Aplicações Azure
Controlos de segurança para o Serviço de Aplicações
Azure
Este artigo documenta os controlos de segurança incorporados no Serviço de Aplicações Azure.

Um controlo de segurança é uma qualidade ou característica de um serviço Azure que contribui para a capacidade
do serviço de prevenir, detetar e responder a vulnerabilidades de segurança.
Para cada controlo, usamos "Sim" ou "Não" para indicar se está atualmente em vigor para o serviço, "N/A" para um
controlo que não é aplicável ao serviço. Podemos também fornecer uma nota ou links para mais informações sobre
um atributo.
Rede
C O N T RO LO DE SEGURA N Ç A SIM / N Ã O N OTA S DO C UM EN TA Ç Ã O
Suporte final de serviço Sim Disponível para Serviço de Restrições de acesso ao

Aplicações. serviço de aplicações Azure
Suporte à injeção VNet Sim Os Ambientes de Serviço de Introdução aos Ambientes

Aplicações são de Serviço de Aplicações
implementações privadas do
App Service dedicadoa a um
único cliente injetado na
rede virtual de um cliente.
Suporte de isolamento de Sim Para a variação pública Restrições de acesso ao

rede e firewalling multi-inquilino do App serviço de aplicações Azure
Service, os clientes podem
configurar acLs de rede
(restrições IP) para bloquear
o tráfego de entrada
permitido. Os Ambientes de
Serviço de Aplicações são
implantados diretamente em
redes virtuais e, portanto,
podem ser protegidos com
NSGs.
Apoio de túnel forçado Sim Os ambientes de serviço de Configurar o Ambiente de

aplicações podem ser Serviço de Aplicações com
implantados na rede virtual túnel forçado
de um cliente onde o túnel
forçado é configurado.
Monitorização & exploração madeireira

Suporte de monitorização Sim O Serviço de Aplicações Monitorize aplicações no

Azure (Análise de registo, integra-se com insights de Serviço de Aplicações Azure
insights de aplicações, etc.) aplicação para idiomas que
suportam insights de
aplicação (Full .NET
Framework, .NET Core, Java
e Node.JS). Consulte o
desempenho do Monitor
Azure App Service. O Serviço
de Aplicações também envia
métricas de aplicação para o
Monitor Azure.
Registo e auditoria de planos Sim Todas as operações de Operaçõesde fornecedor de

de controlo e gestão gestão realizadas em objetos recursos do Gestor de
do Serviço de Aplicações Recursos Azure , az monitor
ocorrem através do Gestor de atividade-log
de Recursos Azure. Os
registos históricos destas
operações estão disponíveis
tanto no portal como
através do CLI.
Registo e auditoria de planos Não O plano de dados do Serviço

de dados de Aplicações é uma partilha
remota de ficheiros
contendo o conteúdo do site
implantado por um cliente.
Não existe auditoria da parte
remota do ficheiro.
Identidade
Autenticação Sim Os clientes podem construir Autenticação e autorização

aplicações no Serviço de no Serviço de Aplicações do
Aplicações que se integrem Azure
automaticamente com o
Azure Ative Directory (Azure
AD), bem como outros
fornecedores de identidade
compatíveis com a OAuth
Para acesso à gestão aos
ativos do App Service, todo
o acesso é controlado por
uma combinação de funções
de diretor audato azure AD e
DoT DBAC do Gestor de
Recursos Azure.
Autorização Sim Para acesso à gestão aos Autenticação e autorização

ativos do Serviço app, todo no Serviço de Aplicações do
o acesso é controlado por Azure
uma combinação de funções
de RBAC autenticados da
Azure AD e do Gestor de
Recursos Azure.
Proteção de dados
Encriptação do lado do Sim O conteúdo do ficheiro do Encriptação azure storage

servidor em repouso: site é armazenado no para dados em repouso
Chaves geridas pela Armazenamento Azure, que
Microsoft encripta automaticamente o
conteúdo em repouso.
Os segredos fornecidos pelo

cliente são encriptados em
repouso. Os segredos são
encriptados em repouso
enquanto armazenados nas
bases de dados de
configuração do Serviço de
Aplicações.
Os discos ligados localmente

podem ser utilizados
opcionalmente como
armazenamento temporário
por websites (D:\local e
%TMP%). Os discos ligados
localmente não são
encriptados em repouso.
Encriptação do lado do Sim Os clientes podem optar por Utilize referências chave
servidor em repouso: chaves armazenar segredos de vault para serviço de
geridas pelo cliente (BYOK) aplicação no Key Vault e aplicações e funções azure
recuperá-los em tempo de (pré-visualização)
funcionamento.
Encriptação de nível de N/D

coluna (Serviços de Dados
Azure)
Encriptação em trânsito Sim Os clientes podem Como fazer um Serviço de

(como encriptação configurar web sites para Aplicações Azure HTTPS
ExpressRoute, na encriptação exigir e usar HTTPS para apenas (post de blog)
VNet e encriptação VNet- tráfego de entrada.
VNet)
Chamadas api encriptadas Sim As chamadas de gestão para

configurar o Serviço de
Aplicações ocorrem através
de chamadas do Gestor de
Recursos Do Azure através
de HTTPS.
Gestão da configuração
Suporte de gestão de Sim Para operações de gestão, o

configuração (versão de estado de uma configuração
configuração, etc.) do Serviço de Aplicações
pode ser exportado como
um modelo de Gestor de
Recursos Azure e versão ao
longo do tempo. Para
operações de tempo de
execução, os clientes podem
manter várias versões ao
vivo diferentes de uma
aplicação utilizando a
funcionalidade de slots de
implementação do Serviço
de Aplicações.
Passos seguintes
Saiba mais sobre os controlos de segurança incorporados em todos os serviços do Azure.
Segurança no Serviço de Aplicações Azure
Este artigo mostra-lhe como o Azure App Service ajuda a proteger a sua aplicação web, aplicação móvel no final,
app API e app de funções. Também mostra como pode proteger ainda mais a sua aplicação com as funcionalidades
do Serviço de Aplicações incorporadas.
Os componentes da plataforma do App Service, incluindo VMs Azure, armazenamento, conexões de rede, quadros
web, funcionalidades de gestão e integração, são ativamente protegidos e endurecidos. O Serviço de Aplicações
passa por controlos de conformidade vigorosos numa base contínua para garantir que:
Os recursos da sua aplicação estão protegidos dos recursos Azure dos outros clientes.
As instâncias vM e o software de tempo de execução são regularmente atualizados para resolver
vulnerabilidades recentemente descobertas.
A comunicação de segredos (como cordas de ligação) entre a sua app e outros recursos Azure (como a Base de
Dados SQL)permanece dentro do Azure e não ultrapassa quaisquer limites de rede. Os segredos são sempre
encriptados quando armazenados.
Toda a comunicação sobre as funcionalidades de conectividade do Serviço app, como a ligação híbrida,está
encriptada.
As ligações com ferramentas de gestão remota como Azure PowerShell, Azure CLI, Azure SDKs, REST APIs, estão
todas encriptadas.
A gestão de ameaças 24 horas protege a infraestrutura e plataforma contra malware, distribuição de negação de
serviço (DDoS), man-in-the-middle (MITM) e outras ameaças.
Para obter mais informações sobre infraestruturas e segurança na plataforma em Azure, consulte o Azure Trust
Center.
As seguintes secções mostram-lhe como proteger ainda mais a sua aplicação de Serviço de Aplicações contra
ameaças.
HTTPS e Certificados
O Serviço de Aplicações permite-lhe proteger as suas aplicações com HTTPS. Quando a sua aplicação é criada, o
seu nome de domínio padrão < (app_name>.azurewebsites.net) já está acessível através do HTTPS. Se configurar
um domínio personalizado para a sua aplicação,também deve alterá-lo com um certificado TLS/SSL para que os
navegadores de clientes possam fazer ligações HTTPS seguras ao seu domínio personalizado. Existem vários tipos
de certificados suportados pelo App Service:
Certificado gerido pelo serviço de aplicações gratuito
Certificado de serviço de aplicações
Certificado de terceiros
Certificado importado do Cofre-Chave Azure
Para mais informações, consulte Adicionar um certificado TLS/SSL no Serviço de Aplicações Azure.
Protocolos inseguros (HTTP, TLS 1.0, FTP)

Para proteger a sua aplicação contra todas as ligações não encriptadas (HTTP), o Serviço de Aplicações fornece uma
configuração de um clique para impor HTTPS. Os pedidos não seguros são rejeitados antes mesmo de chegarem
ao seu código de candidatura. Para mais informações, consulte Enforce HTTPS.
O TLS 1.0 já não é considerado seguro pelas normas da indústria, como o PCI DSS. O Serviço de Aplicações
permite-lhe desativar protocolos desatualizados através da aplicação do TLS 1.1/1.2.
O Serviço de Aplicações suporta ftp e FTPS para a implementação dos seus ficheiros. No entanto, o FTPS deve ser
utilizado em vez de FTP, se possível. Quando um ou ambos os protocolos não estiverem a ser utilizados, deve
desativá-los.
Restrições ip estáticas
Por padrão, a sua aplicação App Service aceita pedidos de todos os endereços IP da internet, mas pode limitar esse
acesso a um pequeno subconjunto de endereços IP. O Serviço de Aplicações no Windows permite definir uma lista
de endereços IP que podem aceder à sua aplicação. A lista permitida pode incluir endereços IP individuais ou uma
série de endereços IP definidos por uma máscara de sub-rede. Para mais informações, consulte as restrições de IP
estáticas do Serviço de Aplicação Azure.
Para o Serviço de Aplicações no Windows, também pode restringir os endereços IP de forma dinâmica
configurando o web.config. Para mais informações, consulte Dynamic IP Security < dynamicIpSecurity>.
Autenticação e autorização do cliente

O Azure App Service fornece autenticação e autorização de utilizadores ou aplicações de clientes. Quando ativado,
pode iniciar sessão em utilizadores e aplicações de clientes com pouco ou nenhum código de aplicação. Pode
implementar a sua própria solução de autenticação e autorização, ou permitir que o Serviço de Aplicações o trate
por si. O módulo de autenticação e autorização trata dos pedidos da Web antes de os entregar ao código de
aplicação, e nega pedidos não autorizados antes de atingirem o seu código.
A autenticação e autorização do Serviço app suportam vários fornecedores de autenticação, incluindo o Azure Ative
Directory, contas Microsoft, Facebook, Google e Twitter. Para obter mais informações, veja Autenticação e
autorização no Serviço de Aplicações do Azure.
Autenticação serviço a serviço

Ao autenticar contra um serviço back-end, o Serviço de Aplicações fornece dois mecanismos diferentes
dependendo da sua necessidade:
Identidade de ser viço - Inscreva-se no recurso remoto utilizando a identidade da própria app. O Serviço de
Aplicações permite-lhe criar facilmente uma identidade gerida, que pode utilizar para autenticar com outros
serviços, como o Azure SQL Database ou o Azure Key Vault. Para um tutorial de ponta a ponta desta abordagem,
consulte a ligação Secure Azure SQL Database do Serviço de Aplicações utilizando uma identidade gerida.
Em nome da OBO (OBO) - Faça o acesso delegado a recursos remotos em nome do utilizador. Com o Azure
Ative Directory como fornecedor de autenticação, a sua aplicação App Service pode realizar sessão delegada
num serviço remoto, como a Microsoft Graph API ou uma aplicação aPI remota no App Service. Para um tutorial
de ponta a ponta desta abordagem, consulte Authenticate e autorize os utilizadores de ponta a ponta no Serviço
de Aplicações Azure.
Conectividade com recursos remotos

Existem três tipos de recursos remotos que a sua app pode necessitar de aceder:
Recursos do Azure
Recursos dentro de uma Rede Virtual Azure
Recursos no local
Em cada um destes casos, o App Service fornece uma forma de fazer ligações seguras, mas ainda deve observar as
melhores práticas de segurança. Por exemplo, utilize sempre ligações encriptadas mesmo que o recurso de back-
end permita ligações não encriptadas. Além disso, certifique-se de que o seu serviço Back-end Azure permite o
conjunto mínimo de endereços IP. Pode encontrar os endereços IP de saída para a sua aplicação em endereços IP de
entrada e saída no Serviço de Aplicações Azure.
Recursos do Azure
Quando a sua aplicação se conecta aos recursos do Azure, como a Base de Dados SQL e o Armazenamento Azure,a
ligação permanece dentro do Azure e não ultrapassa quaisquer limites de rede. No entanto, a ligação passa pela
rede partilhada em Azure, por isso certifique-se sempre de que a sua ligação está encriptada.
Se a sua aplicação estiver hospedada num ambiente de Serviço de Aplicações,deve ligar-se aos serviços Azure
suportados utilizando pontos finais do serviço rede virtual.
Recursos dentro de uma Rede Virtual Azure
A sua aplicação pode aceder a recursos numa Rede Virtual Azure através da integração da Rede Virtual. A
integração é estabelecida com uma Rede Virtual utilizando uma VPN ponto-a-site. A aplicação pode então aceder
aos recursos da Rede Virtual utilizando os seus endereços IP privados. A ligação ponto-a-local, no entanto, ainda
atravessa as redes partilhadas em Azure.
Para isolar completamente a sua conectividade de recursos das redes partilhadas no Azure, crie a sua aplicação
num ambiente de Serviço de Aplicações. Uma vez que um ambiente de Serviço de Aplicações é sempre implantado
para uma Rede Virtual dedicada, a conectividade entre a sua app e os recursos dentro da Rede Virtual está
totalmente isolada. Para outros aspetos da segurança da rede num ambiente de Serviço de Aplicações, consulte o
isolamento da rede.
Recursos no local
Pode aceder de forma segura aos recursos no local, tais como bases de dados, de três formas:
Ligações híbridas - Estabelece uma ligação ponto-a-ponto ao seu recurso remoto através de um túnel TCP. O
túnel TCP é estabelecido utilizando as teclas TLS 1.2 com teclas de assinatura de acesso partilhado (SAS).
Integração da Rede Virtual com VPN site-to-site - Conforme descrito em Recursos dentro de uma Rede Virtual
Azure,mas a Rede Virtual pode ser ligada à sua rede no local através de uma VPN site-to-site. Nesta topologia
da rede, a sua aplicação pode ligar-se a recursos no local, como outros recursos na Rede Virtual.
Ambiente de Serviço de Aplicações com VPN site-to-site - Conforme descrito em Recursos dentro de uma Rede
Virtual Azure, mas a Rede Virtual pode ser ligada à sua rede no local através de uma VPN site-to-site. Nesta
topologia da rede, a sua aplicação pode ligar-se a recursos no local, como outros recursos na Rede Virtual.
Segredos de aplicação
Não guarde segredos de aplicação, tais como credenciais de base de dados, fichas API e chaves privadas no seu
código ou ficheiros de configuração. A abordagem geralmente aceite é acessá-las como variáveis ambientais
usando o padrão padrão na sua linguagem de eleição. No Serviço de Aplicações, a forma de definir variáveis
ambientais é através de definições de aplicações (e, especialmente, para aplicações .NET, cordas de ligação). As
definições de aplicativos e as cordas de ligação são armazenadas encriptadas no Azure, e só são desencriptadas
antes de serem injetadas na memória de processo da sua aplicação quando a aplicação começar. As chaves de
encriptação são rodadas regularmente.
Em alternativa, pode integrar a sua app App Service com o Azure Key Vault para uma gestão avançada de segredos.
Ao aceder ao Key Vault com uma identidade gerida,a sua aplicação App Service pode aceder de forma segura aos
segredos de que necessita.
Isolamento da rede
Com exceção do nível de preços isolados, todos os níveis executam as suas aplicações na infraestrutura de rede
partilhada no Serviço de Aplicações. Por exemplo, os endereços IP públicos e os equilibradores de carga front-end
são partilhados com outros inquilinos. O nível Isolado dá-lhe o isolamento total da rede executando as suas
aplicações dentro de um ambiente dedicado ao Serviço de Aplicações. Um ambiente de serviço de aplicações
funciona no seu próprio exemplo de Rede Virtual Azure. Permite-lhe:
Sirva as suas apps através de um ponto final público dedicado, com extremidades dianteiras dedicadas.
Sirva a aplicação interna utilizando um equilibrador de carga interno (ILB), que permite o acesso apenas a partir
de dentro da sua Rede Virtual Azure. O ILB tem um endereço IP da sua subnet privada, que proporciona o
isolamento total das suas aplicações a partir da internet.
Utilize um ILB por trás de uma firewall de aplicação web (WAF). O WAF oferece proteção ao nível da empresa às
suas aplicações viradas para o público, tais como proteção DDoS, filtragem URI e prevenção de injeção SQL.
Para mais informações, consulte Introdução aos Ambientes de Serviço de Aplicações Azure.
Funcionalidades de rede de serviços de aplicação
As aplicações no Serviço de Aplicações Azure podem ser implementadas de várias formas. Por padrão, as
aplicações hospedadas no App Service são diretamente acessíveis à Internet e só podem chegar a pontos finais
hospedados na Internet. Muitas aplicações de clientes precisam, no entanto, de controlar o tráfego de rede de
entrada e saída. Existem várias funcionalidades disponíveis no Serviço de Aplicações para satisfazer essas
necessidades. O desafio é saber que funcionalidade deve ser usada para resolver um determinado problema. Este
documento destina-se a ajudar os clientes a determinar que funcionalidade deve ser usada com base em alguns
casos de utilização de exemplo.
Existem dois tipos de implantação primários para o Serviço de Aplicações Azure. Existe o serviço público multi-
inquilino, que acolhe planos de Serviço de Aplicações nas SKUs de preços Gratuitos, Partilhados, Básicos, Standard,
Premium e Premiumv2. Depois, há o único inquilino App Service Environment (ASE), que acolhe planos isolados
do Serviço de Aplicações SKU diretamente na sua Rede Virtual Azure (VNet). As funcionalidades que utiliza
variarão se estiver no serviço multi-inquilino ou numa ASE.
Funcionalidades de rede de serviço sinuoso multi-inquilino

O Serviço de Aplicações Azure é um sistema distribuído. As funções que tratam dos pedidos http/HTTPS são
chamadas front-ends. Os papéis que acolhem a carga de trabalho do cliente são chamados trabalhadores. Todas as
funções numa implementação do Serviço de Aplicações existem numa rede multi-arrendatária. Como existem
muitos clientes diferentes na mesma unidade de escala de Serviço de Aplicações, não é possível ligar a rede de
Serviços de Aplicações diretamente à sua rede. Em vez de ligar as redes, precisamos de funcionalidades para lidar
com os diferentes aspetos da comunicação de aplicações. As funcionalidades que lidam com pedidos para a sua
aplicação não podem ser usadas para resolver problemas ao fazer chamadas da sua aplicação. Da mesma forma,
as funcionalidades que resolvem problemas de chamadas da sua aplicação não podem ser usadas para resolver
problemas na sua aplicação.
C A RA C T ERÍST IC A S DE EN T RA DA C A RA C T ERÍST IC A S DE SA ÍDA
Endereço atribuído à aplicação Ligações Híbridas
Restrições de acesso Gateway exigia integração VNet
Pontos Finais de Serviço Integração de VNet
Salvo indicação em contrário, todas as funcionalidades podem ser usadas em conjunto. Pode misturar as
funcionalidades para resolver os seus vários problemas.
Use o estojo e as características

Para qualquer caso de utilização, pode haver algumas formas de resolver o problema. A característica certa a
utilizar deve-se, por vezes, a razões para além do caso de utilização em si. Os seguintes casos de utilização de
entrada sugerem como usar funcionalidades de rede do Serviço app para resolver problemas em torno do
controlo do tráfego que vai para a sua aplicação.
C A SO S DE UT IL IZ A Ç Ã O DE EN T RA DA F UN C IO N A L IDA DE
Suporte as necessidades SSL baseadas em IP para a sua endereço atribuído app

aplicação
Endereço de entrada não partilhado e dedicado para a sua endereço atribuído app
aplicação
Restringir o acesso à sua aplicação a partir de um conjunto de Restrições de acesso

endereços bem definidos
Restringir o acesso à minha app a partir de recursos num Pontos Finais de Serviço
VNet ILB ASE
Ponto final privado (Pré-visualização)
Exponha a minha aplicação num IP privado no meu VNet ILB ASE

IP privado para entrada em um Gateway de aplicação com
pontos finais de serviço
Ponto final de serviço (Pré-visualização)
Proteja a minha aplicação com um WAF Gateway de aplicação + ILB ASE

Gateway de Aplicação com pontos finais de serviço
Porta da frente azure com restrições de acesso
Carregar o tráfego de equilíbrio para as minhas apps em Porta da frente azure com restrições de acesso
diferentes regiões
Tráfego de equilíbrio de carga na mesma região Gateway de Aplicação com pontos finais de serviço
Os seguintes casos de utilização sugerem como utilizar funcionalidades de rede do Serviço de Aplicações para
resolver as necessidades de acesso de saída para a sua aplicação.
C A SO S DE UT IL IZ A Ç Ã O DE SA ÍDA F UN C IO N A L IDA DE
Acesso a recursos numa Rede Virtual Azure na mesma região Integração de VNet
ASE
Acesso a recursos numa Rede Virtual Azure numa região Gateway exigia integração VNet
diferente ASE e VNet espreitando
Recursos de acesso garantidos com pontos finais de serviço Integração de VNet

ASE
Recursos de acesso numa rede privada não ligada ao Azure Ligações Híbridas
Recursos de acesso através dos circuitos ExpressRoute Integração de VNet

ASE
Proteja o tráfego de saída da sua aplicação web Grupos de Integração vNet e segurança da rede
ASE
Rota de tráfego de saída da sua aplicação web Tabelas de Integração e Rota VNet
ASE
Comportamento de rede padrão

As unidades de escala de serviço de aplicação Azure suportam muitos clientes em cada implementação. Os planos
SKU gratuitos e partilhados acolhem cargas de trabalho dos clientes em trabalhadores multi-inquilinos. Os planos
Básicos, e acima dos planos, acolhem cargas de trabalho dos clientes que se dedicam a apenas um plano de
Serviço de Aplicações (ASP). Se você tinha um plano de Serviço de Aplicações Padrão, então todas as aplicações
desse plano serão executadas com o mesmo trabalhador. Se eliminar o trabalhador, todas as aplicações nessa ASP
serão replicadas num novo trabalhador para cada instância no seu ASP. Os trabalhadores que são utilizados para o
Premiumv2 são diferentes dos trabalhadores utilizados para os outros planos. Cada implementação do Serviço de
Aplicações tem um endereço IP que é usado para todo o tráfego de entrada para as aplicações nessa
implementação do Serviço de Aplicações. No entanto, existem entre 4 e 11 endereços usados para fazer chamadas
de saída. Estes endereços são partilhados por todas as aplicações da implementação do Serviço de Aplicações. Os
endereços de saída são diferentes com base nos diferentes tipos de trabalhadores. Isto significa que os endereços
utilizados pelos ASPs Gratuitos, Partilhados, Básicos, Standard e Premium são diferentes dos endereços utilizados
para chamadas de saída dos ASPs Premiumv2. Se procurar nas propriedades para a sua aplicação, pode ver os
endereços de entrada e saída que são utilizados pela sua aplicação. Se precisar de bloquear uma dependência com
um IP ACL, utilize os possíveis Endereços outbound.
O Serviço de Aplicações tem uma série de pontos finais que são usados para gerir o serviço. Estes endereços são
publicados num documento separado e também estão na etiqueta de serviço IP appServiceManagement. A
etiqueta AppServiceManagement só é utilizada com um App Service Environment (ASE) onde é necessário permitir
esse tráfego. Os endereços de entrada do Serviço de Aplicações são rastreados na etiqueta de serviço IP
appService. Não existe nenhuma etiqueta de serviço IP que contenha os endereços de saída utilizados pelo Serviço
de Aplicações.
Endereço atribuído à aplicação

A funcionalidade de endereço atribuída à aplicação é um offshoot da capacidade SSL baseada em IP e é acedida
através da configuração do SSL com a sua aplicação. Esta funcionalidade pode ser utilizada para chamadas SSL
baseadas em IP, mas também pode ser usada para dar à sua aplicação um endereço que só tem.
Quando utiliza um endereço atribuído a uma aplicação, o seu tráfego continua a passar pelas mesmas funções
front-front-end que tratam todo o tráfego de entrada na unidade de escala do Serviço de Aplicações. O endereço
que é atribuído à sua aplicação, no entanto, só é utilizado pela sua aplicação. Os casos de utilização desta
funcionalidade são:
Suporte as necessidades SSL baseadas em IP para a sua aplicação
Detete um endereço dedicado para a sua aplicação que não seja partilhado com mais nada
Pode aprender a definir um endereço na sua aplicação com o tutorial em Adicionar um certificado TLS/SSL no
Restrições de acesso
A capacidade de Restrições de Acesso permite filtrar pedidos de entrada com base no endereço IP de origem. A
ação de filtragem ocorre nas funções frontais que estão a montante das funções dos trabalhadores onde as suas
aplicações estão em execução. Uma vez que as funções front-end são a montante dos trabalhadores, a capacidade
de Restrições de Acesso pode ser considerada como proteção de nível de rede para as suas apps. A funcionalidade
permite-lhe construir uma lista de blocos de endereços de permitir e negar que são avaliados em ordem
prioritária. É semelhante à funcionalidade do Network Security Group (NSG) que existe em Rede Azure. Pode utilizar
esta funcionalidade numa ASE ou no serviço multi-inquilinos. Quando utilizado com um ILB ASE, pode restringir o
acesso a partir de blocos de endereços privados.
A funcionalidade Restrições de Acesso ajuda em cenários em que pretende restringir os endereços IP que podem
ser utilizados para chegar à sua aplicação. Entre os casos de utilização desta funcionalidade encontram-se:
Restringir o acesso à sua aplicação a partir de um conjunto de endereços bem definidos
Restrinja o acesso a um serviço de equilíbrio de carga, como a Porta da Frente Azure. Se quiser bloquear o seu
tráfego de entrada para a Porta Da Frente Azure, crie regras para permitir o tráfego de 147.243.0.0/16 e
2a01:111:2050:/44.
Se deseja bloquear o acesso à sua aplicação para que só possa ser alcançado a partir de recursos da sua Rede
Virtual Azure (VNet), precisa de uma morada pública estática sobre qualquer que seja a sua fonte no seu VNet. Se
os recursos não tiverem um endereço público, deverá utilizar a função De pontos finais de serviço. Saiba como
ativar esta funcionalidade com o tutorial sobre restrições de acesso de configuração.
Pontos finais de serviço
Os pontos finais do serviço permitem bloquear o acesso à entrada da sua aplicação de modo a que o endereço de
origem tenha de vir de um conjunto de subredes que seleciona. Esta funcionalidade funciona em conjunto com as
Restrições de Acesso IP. Os pontos finais do serviço são definidos na mesma experiência do utilizador que as
Restrições de Acesso IP. Pode construir uma lista de regras de acesso que inclua endereços públicos, bem como
subredes nos seus VNets. Esta funcionalidade suporta cenários como:
Configurar um Gateway de Aplicação com a sua app para bloquear o tráfego de entrada na sua app
Restringindo o acesso à sua app aos recursos no seu VNet. Isto pode incluir VMs, ASEs ou mesmo outras
aplicações que usam integração VNet
Pode saber mais sobre configurar pontos finais de serviço com a sua aplicação no tutorial sobre restrições de
acesso ao fim do serviço de configuração
Ponto final privado (Pré -visualização )
Private Endpoint é uma interface de rede que o conecta de forma privada e segura à sua Web App por Azure
Private Link. O Private Endpoint utiliza um endereço IP privado do seu VNet, efetivamente trazendo a Aplicação
Web para o seu VNet. Esta funcionalidade destina-se apenas aos fluxos de entrada para a sua Web App. Utilização
de pontos finais privados para aplicação web azure (pré-visualização)
Ligações Híbridas
O Serviço de Aplicações Ligações Híbridas permite que as suas apps efaçam chamadas de saída para pontos
finais específicos do TCP. O ponto final pode estar no local, num VNet ou em qualquer lugar que permita o tráfego
de saída para Azure no porto 443. A funcionalidade requer a instalação de um agente de retransmissão chamado
Hybrid Connection Manager (HCM) num Windows Server 2012 ou num novo anfitrião. O HCM precisa de ser
capaz de chegar ao Relé Azure na porta 443. O HCM pode ser descarregado a partir do App Service Hybrid
Connections UI no portal.
A funcionalidade De Ligações Híbridas do Serviço app é construída com base na capacidade de Ligações Híbridas
Azure Relay. O Serviço de Aplicações utiliza uma forma especializada da funcionalidade que apenas suporta fazer
chamadas de saída da sua app para um anfitrião e porta TCP. Este hospedeiro e porta só precisam de ser resolvidos
no hospedeiro onde o HCM está instalado. Quando a aplicação, no Serviço de Aplicações, faz uma verificação DNS
sobre o hospedeiro e a porta definida sem ligação híbrida, o tráfego é automaticamente redirecionado para passar
pela Ligação Híbrida e sair do Hybrid Connection Manager. Para saber mais sobre Ligações Híbridas, leia a
documentação sobre ligações híbridas do Serviço de Aplicações
Esta funcionalidade é comumente usada para:
Aceder a recursos em redes privadas que não estejam ligados ao Azure com uma VPN ou ExpressRoute
Suporte levantar e transferir aplicações no local para O Serviço de Aplicações sem necessidade de mover
também bases de dados de suporte
Forneça de forma segura acesso a um único hospedeiro e porta por conexão híbrida. A maioria das
funcionalidades de networking abre acesso a uma rede e com Conexões Híbridas só tem o único anfitrião e
porta que pode alcançar.
Cobrir cenários não abrangidos por outros métodos de conectividade de saída
Realizar desenvolvimento no App Service onde as aplicações podem facilmente alavancar recursos no local
Uma vez que a funcionalidade permite o acesso aos recursos no local sem um buraco de firewall de entrada, é
popular entre os desenvolvedores. As outras funcionalidades de rede de serviços de aplicações de saída estão
muito relacionadas com a Rede Virtual Azure. As Ligações Híbridas não têm uma dependência de passar por um
VNet e podem ser usadas para uma maior variedade de necessidades de networking. É importante notar que a
funcionalidade De Ligações Híbridas do Serviço app não se importa ou sabe o que está a fazer em cima dela. Isto é,
pode usá-lo para aceder a uma base de dados, a um serviço web ou a uma tomada tCP arbitrária num computador
principal. A funcionalidade essencialmente túneis pacotes TCP.
Embora a Hybrid Connections seja popular para o desenvolvimento, também é usada em numerosas aplicações de
produção. É ótimo para aceder a um serviço web ou base de dados, mas não é apropriado para situações que
envolvam a criação de muitas conexões.
Gateway exigia integração VNet
A funcionalidade de integração VNet do Serviço de Aplicação necessária permite que a sua aplicação evoque
pedidos de saída numa Rede Virtual Azure. A funcionalidade funciona ligando o anfitrião que a sua aplicação está
a correr para um portal de rede virtual no seu VNet com uma VPN ponto-a-site. Ao configurar a funcionalidade, a
sua aplicação obtém um dos endereços ponto-a-site atribuídos a cada instância. Esta funcionalidade permite-lhe
aceder a recursos em VNets Clássicos ou Gestorde Recursos em qualquer região.
Esta funcionalidade resolve o problema de aceder a recursos noutros VNets e pode mesmo ser usada para ligar
através de um VNet a outros VNets ou até mesmo no local. Não funciona com VNets ligados à ExpressRoute, mas
sim com redes conectadas VPN site-to-site. Normalmente é inapropriado utilizar esta funcionalidade a partir de
uma aplicação num App Service Environment (ASE), porque a ASE já se encontra no seu VNet. Os casos de
utilização que esta funcionalidade resolve são:
Acesso a recursos em IPs privados nas suas redes virtuais Azure
Acesso a recursos no local se houver uma VPN site-to-site
Acesso a recursos em VNets peered
Quando esta funcionalidade estiver ativada, a sua aplicação utilizará o servidor DNS com o qual o destino VNet
está configurado. Pode ler mais sobre esta funcionalidade na documentação sobre a Integração VNet do Serviço de
Aplicações.
Integração de VNet
A funcionalidade de Integração VNet necessária é muito útil, mas ainda não resolve o acesso aos recursos através
do ExpressRoute. Além de precisar de contactar as ligações ExpressRoute, é necessário que as aplicações possam
fazer chamadas para serviços seguros de ponto final. Para resolver ambas as necessidades adicionais, foi
adicionada outra capacidade de Integração VNet. A nova funcionalidade de Integração VNet permite-lhe colocar o
backend da sua aplicação numa subnet numa VNet gestora de recursos na mesma região. Esta funcionalidade não
está disponível a partir de um App Service Environment, que já se encontra num VNet. Esta funcionalidade
permite:
Acesso a recursos em VNets gestor de recursos na mesma região
Acesso a recursos que são assegurados com pontos finais de serviço
Acesso a recursos acessíveis através de conexões ExpressRoute ou VPN
Assegurar todo o tráfego de saída
Forçar a escavar todo o tráfego de saída.
Para saber mais sobre esta funcionalidade, leia os docs no App Service VNet Integration.
Ambiente do Serviço de Aplicações

Um App Service Environment (ASE) é uma implantação única do Serviço de Aplicações Azure que funciona no seu
VNet. A ASE permite a utilização de casos como:
Acesso a recursos no seu VNet
Acesso a recursos através do ExpressRoute
Exponha as suas apps com um endereço privado no seu VNet
Aceder a recursos através de pontos finais de serviço
Com uma ASE, não precisa de utilizar funcionalidades como a Integração VNet ou pontos finais de serviço porque
a ASE já se encontra no seu VNet. Se pretender aceder a recursos como o SQL ou o Storage sobre os pontos finais
do serviço, ative pontos finais de serviço na subnet ASE. Se quiser aceder aos recursos no VNet, não é necessária
uma configuração adicional. Se quiser aceder a recursos através do ExpressRoute, já se encontra no VNet e não
precisa de configurar nada na ASE ou nas aplicações no seu interior.
Como as aplicações de um ILB ASE podem ser expostas num endereço IP privado, pode facilmente adicionar
dispositivos WAF para expor apenas as aplicações que deseja para a internet e manter o resto seguro. Presta-se a
um fácil desenvolvimento de aplicações de vários níveis.
Há algumas coisas que ainda não são possíveis do serviço multi-inquilinos que são de uma ASE. Estas incluem
coisas como:
Exponha as suas aplicações num endereço IP privado
Proteja todo o tráfego de saída com controlos de rede que não fazem parte da sua app
Hospedar as suas apps num único serviço de inquilinos
Escala até muitos mais instâncias do que é possível no serviço multi-inquilinos
Carregue certificados de cliente ca privados para uso pelas suas apps com pontos finais seguros CA privados
Force TLS 1.1 em todas as aplicações hospedadas no sistema sem qualquer capacidade de desativar ao nível da
aplicação
Forneça um endereço de saída dedicado para todas as aplicações da sua ASE que não seja partilhada com
nenhum cliente
A ASE oferece a melhor história em torno de hospedagem de apps isoladas e dedicadas, mas vem com alguns
desafios de gestão. Algumas coisas a considerar antes de usar uma ASE operacional são:
Uma ASE corre dentro do seu VNet mas tem dependências fora do VNet. Essas dependências devem ser
permitidas. Ler mais em considerações de Networking para um Ambiente de Serviço de Aplicações
Uma ASE não escala imediatamente como o serviço multi-inquilinos. É preciso antecipar as necessidades de
escala em vez de escalar reactivamente.
Uma ASE tem um custo frontal mais elevado associado a ele. Para tirar o máximo partido da sua ASE, deve
planear colocar muitas cargas de trabalho numa ASE em vez de a utilizar para pequenos esforços.
As aplicações numa ASE não podem restringir o acesso a algumas aplicações numa ASE e não noutras.
A ASE encontra-se numa subrede e todas as regras de rede aplicam-se a todo o tráfego de e para a ASE. Se
quiser atribuir regras de tráfego de entrada para apenas uma aplicação, utilize restrições de acesso.
Combinando funcionalidades
As funcionalidades notadas para o serviço multi-inquilinos podem ser utilizadas em conjunto para resolver casos
de utilização mais elaborados. Dois dos casos de utilização mais comuns são descritos aqui, mas são apenas
exemplos. Ao entender o que as várias funcionalidades fazem, pode resolver quase todas as necessidades da
arquitetura do seu sistema.
Injetar app num VNet
Um pedido comum é sobre como colocar a sua aplicação num VNet. Colocar a sua aplicação num VNet significa
que os pontos finais de entrada e saída para uma aplicação estão dentro de um VNet. A ASE fornece a melhor
solução para resolver este problema, mas pode obter a maior parte do que é necessário no serviço multi-
inquilinos, combinando funcionalidades. Por exemplo, pode alojar aplicações intranet apenas com endereços de
entrada e saída privados por:
Criação de um Gateway de Aplicação com endereço de entrada e saída privado
Garantir o tráfego de entrada na sua app com pontos finais de serviço
Use a nova Integração VNet para que o backend da sua aplicação esteja no seu VNet
Este estilo de implementação não lhe daria um endereço dedicado para tráfego de saída para a internet ou lhe
daria a capacidade de bloquear todo o tráfego de saída da sua app. Este estilo de implantação dar-lhe-ia muito do
que só de outra forma conseguiria com uma ASE.
Criar aplicações de vários níveis
Uma aplicação de vários níveis é uma aplicação onde as aplicações de backend da API só podem ser acedidas a
partir do nível frontal. Para criar uma aplicação de vários níveis, pode:
Utilize a Integração VNet para ligar o backend da sua aplicação web frontal com uma subnet num VNet
Utilize pontos finais de serviço para garantir o tráfego de entrada na sua aplicação API apenas para vir da
subnet utilizada pela sua aplicação web frontal
Pode ter várias aplicações front-end a utilizar a mesma aplicação API utilizando a Integração VNet a partir das
outras aplicações frontais e pontos finais de serviço da aplicação API com as suas subredes.
Integração de Gateway de aplicação com pontos
finais de serviço
Existem três variações do Serviço de Aplicações que requerem uma configuração ligeiramente diferente da
integração com o Portal de Aplicações Azure. As variações incluem o Serviço regular de Aplicações - também
conhecido como multi-inquilino, Internal Load Balancer (ILB) App Service Environment (ASE) e ASE Externa. Este
artigo irá analisar como configurá-lo com o App Service (multi-inquilino) e discutir considerações sobre iLB, e ASE
Externa.
Integração com o App Service (multi-inquilino)

O App Service (multi-inquilino) tem um ponto final virado para a internet pública. Utilizando pontos finais de
serviço, só pode permitir o tráfego a partir de uma subrede específica dentro de uma Rede Virtual Azure e
bloquear tudo o resto. No seguinte cenário, usaremos esta funcionalidade para garantir que uma instância do
Serviço de Aplicações só pode receber tráfego a partir de uma instância específica do Gateway de aplicações.
Existem duas partes nesta configuração além de criar o Serviço de Aplicações e o Gateway de Aplicações. A
primeira parte é permitir pontos finais de serviço na subnet da Rede Virtual onde o Gateway de Aplicação é
implementado. Os pontos finais do serviço garantirão que todo o tráfego de rede que saia da subnet para o
Serviço de Aplicações será marcado com o ID da sub-rede específico. A segunda parte é definir uma restrição de
acesso da aplicação web específica para garantir que apenas o tráfego marcado com este ID de sub-rede específico
é permitido. Pode configurá-lo utilizando diferentes ferramentas dependendo da preferência.
Com o Portal do Azure

Com o portal Azure, siga quatro passos para fornecer e configurar a configuração. Se tiver recursos existentes,
pode saltar os primeiros passos.
1. Criar um Serviço de Aplicações utilizando um dos Quickstarts na documentação do Serviço de Aplicações, por
exemplo.Net Core Quickstart
2. Crie um Gateway de Aplicação utilizando o portal Quickstart,mas ignore a secção de alvos add end.
3. Configure o Serviço de Aplicações como um backend no Gateway de Aplicações,mas ignore a secção de acesso
restrito.
4. Finalmente crie a restrição de acesso utilizando pontos finaisde serviço .
Agora pode aceder ao Serviço de Aplicações através do Gateway de Aplicações, mas se tentar aceder diretamente
ao Serviço de Aplicações, deverá receber um erro de 403 HTTP indicando que o web site está parado.
Com o modelo do Azure Resource Manager

O modelo de implementação do Gestor de Recursos fornecerá um cenário completo. O cenário consiste numa
instância do Serviço de Aplicações bloqueada com pontos finais de serviço e restrição de acesso para apenas
receber tráfego a partir do Gateway de aplicação. O modelo inclui muitos Prenúis Inteligentes e fixos postais
únicos adicionados aos nomes de recursos para que seja simples. Para os anular, terá de clonar o repo ou baixar o
modelo e editá-lo.
Para aplicar o modelo pode utilizar o botão Deploy para Azure encontrado na descrição do modelo, ou pode
utilizar powerShell/CLI apropriado.
Usando interface de linha de comando Azure

A amostra Azure CLI fornecerá um Serviço de Aplicações bloqueado com pontos finais de serviço e restrição de
acesso para apenas receber tráfego a partir do Gateway de aplicação. Se necessitar apenas de isolar o tráfego de
um serviço de aplicações existente a partir de um Gateway de Aplicações existente, o seguinte comando é
suficiente.
az webapp config access-restriction add --resource-group myRG --name myWebApp --rule-name AppGwSubnet --
priority 200 --subnet mySubNetName --vnet-name myVnetName
Na configuração predefinida, o comando garantirá a configuração do ponto final do serviço na sub-rede e a

restrição de acesso no Serviço de Aplicações.
Considerações para a ILB ASE

O ILB ASE não está exposto à internet e o tráfego entre a instância e um Gateway de aplicação já está isolado na
Rede Virtual. O seguinte guia configura um ILB ASE e integra-o com um Gateway de Aplicação utilizando o portal
Azure.
Se pretender garantir que apenas o tráfego a partir da subnet Application Gateway está a chegar à ASE, pode
configurar um grupo de segurança de rede (NSG) que afeta todas as aplicações web na ASE. Para o NSG, é possível
especificar a gama IP da sub-rede e opcionalmente as portas (80/443). Certifique-se de que não anula as regras de
NSG necessárias para que a ASE funcione corretamente.
Para isolar o tráfego de uma aplicação web individual, terá de utilizar restrições de acesso baseadas em IP, uma vez
que os pontos finais do serviço não funcionarão para a ASE. O endereço IP deve ser o IP privado da instância De
entrada de aplicações.
Considerações para a ASE Externa

A ASE externa tem um equilibrador de carga virado para o público como o Serviço de Aplicações multi-inquilinos.
Os pontos finais do serviço não funcionam para a ASE, e é por isso que terá de usar restrições de acesso baseadas
em IP utilizando o IP público da instância de Gateway de Aplicação. Para criar uma ASE Externa utilizando o portal
Azure, pode seguir este Quickstart
Considerações para o site kudu/scm

O site Scm, também conhecido como kudu, é um site de administração, que existe para cada aplicação web. Não é
possível inverter o proxy do site scm e provavelmente também quer bloqueá-lo em endereços IP individuais ou
uma sub-rede específica.
Se pretender utilizar as mesmas restrições de acesso que o site principal, pode herdar as definições utilizando o
seguinte comando.
az webapp config access-restriction set --resource-group myRG --name myWebApp --use-same-restrictions-for-scm-

site
Se pretender definir restrições de acesso individuais para o site scm, pode adicionar restrições de acesso utilizando
a bandeira do site --scm como mostrado abaixo.
az webapp config access-restriction add --resource-group myRG --name myWebApp --scm-site --rule-name
KudoAccess --priority 200 --ip-address 208.130.0.0/16
Passos seguintes
Para obter mais informações sobre o Ambiente do Serviço de Aplicações, consulte a documentação do Ambiente
do Serviço de Aplicações.
Para garantir ainda mais a sua aplicação web, as informações sobre o Firewall da Aplicação Web no Gateway de
Aplicações podem ser encontradas na documentação de Firewall da Aplicação Web do Azure.
Utilização de pontos finais privados para app Web
Azure (pré-visualização)
NOTE
Com a atualização de pré-visualização, divulgámos a funcionalidade de proteção de exfiltração de dados.
A pré-visualização está disponível em todas as regiões públicas para As Aplicações Web PremiumV2 e Linux Web e Funções
Premium Elásticas.
Pode utilizar o Private Endpoint para a sua Azure Web App para permitir que os clientes localizados na sua rede
privada acedam de forma segura à aplicação sobre o Private Link. O Private Endpoint utiliza um endereço IP a
partir do seu espaço de endereço Azure VNet. O tráfego de rede entre um cliente na sua rede privada e a Web App
atravessa o VNet e uma Ligação Privada na rede de espinha dorsal da Microsoft, eliminando a exposição da
Internet pública.
A utilização de Ponto Final Privado para a sua Aplicação Web permite-lhe:
Proteja a sua Web App configurando o Ponto Final Privado, eliminando a exposição pública.
Ligue-se seguramente à Web App a partir de redes no local que se conectam ao VNet usando um VPN ou
ExpressRoute private peering.
Evite qualquer exfiltração de dados do seu VNet.
Se necessitar apenas de uma ligação segura entre o seu VNet e a sua Web App, um Ponto Final de Serviço é a
solução mais simples. Se também precisar de chegar à aplicação web a partir do local através de um gateway
Azure, um VNet com olhos regionais ou um VNet globalmente espreitado, o Private Endpoint é a solução.
Para mais informações, consulte os Pontos finais de serviço.
Descrição geral conceptual

Um Ponto Final Privado é uma interface de rede especial (NIC) para a sua App Web Azure numa sub-rede na sua
Rede Virtual (VNet). Quando cria um Ponto Final Privado para a sua Web App, proporciona uma conectividade
segura entre os clientes da sua rede privada e a sua Web App. O Ponto Final Privado é atribuído a um endereço IP a
partir do intervalo de endereços IP do seu VNet. A ligação entre o Ponto Final Privado e a Web App utiliza uma
ligação privadasegura. O Ponto Final Privado é utilizado apenas para fluxos de entrada na sua Web App. Os fluxos
de saída não utilizarão este Ponto Final Privado, mas pode injetar fluxos de saída para a sua rede numa sub-rede
diferente através da funcionalidade de integração VNet.
A sub-rede onde se liga o Ponto Final Privado pode ter outros recursos, não precisa de uma Sub-rede vazia
dedicada. Também pode implementar o Private Endpoint numa região diferente da Web App.
NOTE
A funcionalidade de integração VNet não pode utilizar a mesma sub-rede que o Private Endpoint, esta é uma limitação da
funcionalidade de integração VNet.
Do ponto de vista da segurança:

Quando ativa os Pontos Finais Privados da sua Web App, desativa todo o acesso público.
Pode ativar vários Pontos Finais Privados em outros VNets e Subnets, incluindo VNets noutras regiões.
O endereço IP do Private Endpoint NIC deve ser dinâmico, mas permanecerá o mesmo até eliminar o Ponto
Final Privado.
O NIC do Private Endpoint não pode ter um NSG associado.
A sub-rede que acolhe o Private Endpoint pode ter um NSG associado, mas tem de desativar as políticas de rede
para o Ponto Final Privado: ver políticas de rede de desativação para pontos finais privados. Como resultado,
não é possível filtrar por nenhum NSG o acesso ao seu Ponto Final Privado.
Quando ativa o Private Endpoint para a sua Web App, a configuração das restrições de acesso da Web App não
é avaliada.
Pode eliminar o risco de exfiltração de dados do VNet removendo todas as regras NSG onde o destino é a
marca Internet ou os serviços Azure. Quando implementa um Ponto Final Privado para uma Aplicação Web, só
pode chegar a esta Aplicação Web específica através do Ponto Final Privado. Se tiver outra Web App, tem de
implementar outro Ponto Final Privado dedicado para esta outra Web App.
Nos registos HTTP web da sua Web App, encontrará o IP de origem do cliente. Isto é implementado usando o
protocolo TCP Proxy, reencaminhando a propriedade IP do cliente até a Web App. Para obter mais informações,
consulte obter informações de ligação utilizando o TCP Proxy v2.
DNS
Como esta funcionalidade está em pré-visualização, não alteramos a entrada de DNS durante a pré-visualização.
Você precisa de gerir a entrada DNS no seu servidor DNS privado ou na zona privada do Azure DNS. Se precisar de
usar um nome DNS personalizado, tem de adicionar o nome personalizado na sua Web App. Durante a pré-
visualização, o nome personalizado deve ser validado como qualquer nome personalizado, utilizando a resolução
pública de DNS. Para mais informações, consulte a validação personalizada do DNS.
Se precisar de utilizar a consola Kudu, ou a API Kudu REST (implantação com agentes auto-hospedados da Azure
DevOps, por exemplo), precisa de criar dois registos na sua zona privada Azure DNS ou no seu servidor DNS
personalizado.
PrivateEndpointIP yourwebappname.azurewebsites.net
PrivateEndpointIP yourwebappname.scm.azurewebsites.net
Preços
Para obter detalhes sobre os preços, consulte os preços do Azure Private Link.
Limitações
Quando utilizar a Função Azure em Plano Premium Elástico com Ponto Final Privado, para executar ou executar a
função no portal Azure Web, tem de ter acesso direto à rede ou receberá um erro HTTP 403. Por outras palavras, o
seu navegador deve ser capaz de chegar ao Ponto Final Privado para executar a função a partir do portal Azure
Web.
Durante a pré-visualização, apenas a ranhura de produção é exposta por trás do Private Endpoint, outras ranhuras
devem ser alcançadas pelo Public Endpoint.
Estamos a melhorar regularmente o recurso Private Link e o Private Endpoint, consulte este artigo para obter
informações atualizadas sobre limitações.
Próximos passos
Para implementar o ponto final privado para a sua Web App através do portal ver como ligar-se privadamente a
uma Aplicação Web
Endereços IP de entrada e saída no Serviço de
Aplicações Azure
O Azure App Service é um serviço multi-inquilino, com exceção dos Ambientes de Serviço de Aplicações. As
aplicações que não se encontram num ambiente de Serviço de Aplicações (não no nível isolado)partilham a
infraestrutura de rede com outras aplicações. Como resultado, os endereços IP de entrada e saída de uma
aplicação podem ser diferentes, e podem até mudar em determinadas situações.
Os Ambientes de Serviço de Aplicações utilizam infraestruturas de rede dedicadas, pelo que as aplicações que
executam um ambiente de Serviço de Aplicações obtêm endereços IP estáticos e dedicados tanto para ligações de
entrada como para saída.
Quando o IP de entrada muda

Independentemente do número de instâncias escalonadas, cada aplicação tem um único endereço IP de entrada.
O endereço IP de entrada pode ser alterado quando executa uma das seguintes ações:
Elimine uma aplicação e recrie-a num grupo de recursos diferente.
Elimine a última aplicação numa combinação de grupo de recursos e região e recrie-a.
Eliminar uma ligação TLS existente, como durante a renovação do certificado (ver certificado Renovar).
Encontre o IP de entrada
Basta executar o seguinte comando num terminal local:
nslookup <app-name>.azurewebsites.net
Obtenha um IP estático de entrada

Às vezes, pode querer um endereço IP dedicado e estático para a sua aplicação. Para obter um endereço IP de
entrada estático, precisa de garantir um domínio personalizado. Se não necessitar de funcionalidade TLS para
proteger a sua aplicação, pode até fazer o upload de um certificado auto-assinado para esta ligação. Numa ligação
ip-based TLS, o certificado está ligado ao próprio endereço IP, pelo que o Serviço de Aplicações prevê um
endereço IP estático para que isso aconteça.
Quando os IPs de saída mudam

Independentemente do número de instâncias escalonadas, cada aplicação tem um número definido de endereços
IP de saída a qualquer momento. Qualquer ligação de saída da aplicação do Serviço de Aplicações, como uma
base de dados de back-end, utiliza um dos endereços IP de saída como endereço IP de origem. Não é possível
saber previamente qual o endereço IP que uma determinada instância de aplicação utilizará para fazer a ligação
de saída, pelo que o seu serviço back-end deve abrir a sua firewall a todos os endereços IP de saída da sua
aplicação.
O conjunto de endereços IP de saída para a sua aplicação muda quando escala a sua aplicação entre os níveis
inferiores (Básico, Standard e Premium) e o nível Premium V2.
Pode encontrar o conjunto de todos os possíveis endereços IP de saída que a possibleOutboundIpAddresses sua
aplicação possa utilizar, independentemente dos níveis de preços, procurando a propriedade ou no campo
adicional de endereços IP outbound na lâmina Propriedades no portal Azure. Ver Localizar IPs de saída.
Descubra iPs de saída

Para encontrar os endereços IP de saída atualmente utilizados pela sua aplicação no portal Azure, clique em
Propriedades na navegação à esquerda da sua aplicação. Estão listados no campo de endereços IP outbound.
Pode encontrar as mesmas informações executando o seguinte comando na Cloud Shell.
az webapp show --resource-group <group_name> --name <app_name> --query outboundIpAddresses --output tsv
(Get-AzWebApp -ResourceGroup <group_name> -name <app_name>).OutboundIpAddresses
Para encontrar todos os possíveis endereços IP de saída para a sua aplicação, independentemente dos níveis de
preços, clique em Propriedades na navegação à esquerda da sua aplicação. Estão listados no campo de
endereços IP de saída adicional.
Pode encontrar as mesmas informações executando o seguinte comando na Cloud Shell.
az webapp show --resource-group <group_name> --name <app_name> --query possibleOutboundIpAddresses --output

tsv
(Get-AzWebApp -ResourceGroup <group_name> -name <app_name>).PossibleOutboundIpAddresses
Passos seguintes
Aprenda a restringir o tráfego de entrada através de endereços IP de origem.
Restrições ip estáticas
Integre a sua app com uma rede virtual Azure
Este artigo descreve a funcionalidade de Integração VNet do Serviço de Aplicações Azure e como conehá-la com
aplicações no Azure App Service. Com a Rede Virtual Azure (VNets), pode colocar muitos dos seus recursos Azure
numa rede não-internet-routable. A funcionalidade de Integração VNet permite que as suas aplicações acedam a
recursos dentro ou através de um VNet. A Integração VNet não permite que as suas aplicações sejam acedidas em
privado.
O Azure App Service tem duas variações na funcionalidade de Integração VNet:
Os sistemas multiarrendatários que suportam toda a gama de planos de preços exceto isolados.
O App Service Environment, que se implanta no seu VNet e suporta aplicações de planos de preços isolados.
A funcionalidade de Integração VNet é utilizada em aplicações multiarrendatárias. Se a sua aplicação estiver no App
Service Environment, então já está num VNet e não requer a utilização da funcionalidade de Integração VNet para
chegar a recursos no mesmo VNet. Para obter mais informações sobre todas as funcionalidades de networking,
consulte as funcionalidades de rede do Serviço de Aplicações.
A VNet Integration dá à sua aplicação acesso aos recursos no seu VNet, mas não concede acesso privado à sua
aplicação a partir do VNet. O acesso ao site privado refere-se a tornar uma aplicação acessível apenas a partir de
uma rede privada, como por exemplo dentro de uma rede virtual Azure. A VNet Integration é usada apenas para
fazer chamadas de saída da sua aplicação para o seu VNet. A funcionalidade de Integração VNet comporta-se de
forma diferente quando é usada com VNet na mesma região e com VNet noutras regiões. A funcionalidade de
Integração VNet tem duas variações:
Integração VNet Regional : Quando se conecta a redes virtuais do Azure Resource Manager na mesma região,
deve ter uma subnet dedicada no VNet com o qual está a integrar.
Integração VNet exigida por Gateway : Quando se conecta à VNet noutras regiões ou a uma rede virtual
clássica na mesma região, precisa de um gateway de rede virtual Azure aprovisionado no Alvo VNet.
As funcionalidades de Integração VNet:
Exija um plano de preços Standard, Premium, PremiumV2 ou Elástico Premium.
Suporte TCP e UDP.
Trabalhe com aplicações do Azure App Service e aplicações de função.
Há algumas coisas que a VNet Integração não suporta, como:
Montando uma unidade.
Integração de Diretório ativo.
NetBIOS.
A VNet Integration exigida por gateway fornece acesso a recursos apenas no VNet alvo ou em redes ligadas ao alvo
VNet com peering ou VPNs. A VNet Integration exigida por Gateway não permite o acesso aos recursos disponíveis
em ligações Azure ExpressRoute ou trabalha com pontos finais de serviço.
Independentemente da versão utilizada, a VNet Integration dá à sua aplicação acesso aos recursos no seu VNet,
mas não concede acesso privado à sua aplicação a partir do VNet. O acesso ao site privado refere-se a tornar a sua
aplicação acessível apenas a partir de uma rede privada, como por exemplo dentro de um Azure VNet. A VNet
Integration é apenas para fazer chamadas de saída da sua aplicação para o seu VNet.
Ativar a integração do VNet
1. Aceda ao UI de Rede no portal do Serviço de Aplicações. Em Integração VNet, selecione Clique aqui
para configurar .
2. Selecione Adicionar VNet .
3. A lista de drop-down contém todas as redes virtuais do Azure Resource Manager na sua subscrição na
mesma região. Por baixo disso está uma lista das redes virtuais do Gestor de Recursos em todas as outras
regiões. Selecione o VNet com o quais pretende integrar-se.
Se o VNet estiver na mesma região, ou crie uma nova sub-rede ou selecione uma sub-rede pré-existente
vazia.
Para selecionar um VNet noutra região, tem de ter um gateway VNet atado com o ponto para o site
ativado.
Para se integrar com um VNet clássico, em vez de selecionar a lista de drop-down da Rede Vir tual,
selecione Clique aqui para ligar a um VNet clássico . Selecione a rede virtual clássica que deseja. O
VNet alvo já deve ter um gateway de rede virtual a provisionado com o ponto a local ativado.
Durante a integração, a sua aplicação é reiniciada. Quando a integração estiver terminada, verá detalhes sobre o
VNet com o qual está integrado.
Integração Regional de VNet

A utilização da Integração VNet regional permite que a sua aplicação aceda:
Recursos num VNet na mesma região que a sua aplicação.
Os recursos em VNets espreguiçadados para o VNet a sua aplicação está integrada.
Serviços seguros de serviço.
Recursos através das ligações Azure ExpressRoute.
Recursos no VNet com os qual está integrado.
Recursos através de ligações espreitadas, que incluem ligações Azure ExpressRoute.
Pontos finais privados
Quando utilizar a Integração VNet com VNets na mesma região, pode utilizar as seguintes funcionalidades de
networking Azure:
Grupos de segurança de rede (NSGs) : Pode bloquear o tráfego de saída com um NSG colocado na sua sub-
rede de integração. As regras de entrada não se aplicam porque não pode usar a Integração VNet para fornecer
acesso à sua aplicação.
Tabelas de rotas (UDRs) : Pode colocar uma tabela de rota na sub-rede de integração para enviar o tráfego de
saída onde quiser.
Por padrão, a sua aplicação apenas encaminha o tráfego RFC1918 para o seu VNet. Se quiser encaminhar todo o
tráfego de saída para o seu VNet, aplique a definição da aplicação WEBSITE_VNET_ROUTE_ALL para a sua aplicação.
Para configurar a definição da aplicação:
1. Aceda ao UI de configuração no portal da aplicação. Selecione nova definição de aplicação .
2. Introduza WEBSITE_VNET_ROUTE_ALL na caixa Nome e introduza 1 na caixa Valor.
3. Selecione OK .
4. Selecione Guardar .
Se encaminhar todo o tráfego de saída para o seu VNet, está sujeito aos NSGs e UDRs que são aplicados na sua
sub-rede de integração. Quando encaminha todo o tráfego de saída para o seu VNet, os seus endereços de saída
ainda são os endereços de saída que estão listados nas propriedades da sua aplicação, a menos que forneça rotas
para enviar o tráfego para outro lugar.
Existem algumas limitações com a utilização da Integração VNet com VNets na mesma região:
Não se pode alcançar recursos através de ligações globais de observação.
A funcionalidade está disponível apenas a partir de novas unidades de escala do Azure App Service que
suportam planos do Serviço de Aplicações PremiumV2.
A sub-rede de integração pode ser utilizada apenas por um plano de Serviço de Aplicações.
A funcionalidade não pode ser utilizada por aplicações de plano isolado que se encontrem num Ambiente de
A funcionalidade requer uma sub-rede não utilizada que seja uma /27 com 32 endereços ou maior num VNet
do Gestor de Recursos Azure.
A aplicação e o VNet devem estar na mesma região.
Não é possível eliminar um VNet com uma aplicação integrada. Remova a integração antes de eliminar o VNet.
Só é possível integrar-se com VNets na mesma subscrição que a aplicação.
Você pode ter apenas uma integração regional VNet por plano de Serviço de Aplicação. Várias aplicações no
mesmo plano de Serviço de Aplicações podem usar o mesmo VNet.
Não é possível alterar a subscrição de uma app ou de um plano enquanto há uma aplicação que está a usar a
Integração VNet regional.
A sua aplicação não consegue resolver endereços em Zonas Privadas Azure DNS sem alterações de
configuração
Um endereço é usado para cada instância de plano. Se escalar a sua aplicação em cinco instâncias, então são
utilizados cinco endereços. Uma vez que o tamanho da sub-rede não pode ser alterado após a atribuição, você deve
usar uma sub-rede que é grande o suficiente para acomodar qualquer escala que a sua app possa alcançar. Um /26
com 64 endereços é o tamanho recomendado. A /26 com 64 endereços acomoda um plano Premium com 30
instâncias. Quando escala um plano para cima ou para baixo, você precisa do dobro de endereços por um curto
período de tempo.
Se quiser que as suas apps num outro plano cheguem a um VNet que já esteja ligado a apps noutro plano,
selecione uma sub-rede diferente da que está a ser usada pela integração VNet pré-existente.
A funcionalidade é totalmente suportada tanto para aplicações web Windows como Linux. Todos os
comportamentos agem da mesma forma entre aplicações Windows e aplicações Linux.
A Integração Regional de VNet permite-lhe utilizar pontos finais de serviço. Para utilizar pontos finais de serviço
com a sua aplicação, utilize a Integração Regional de VNet para ligar a um VNet selecionado e, em seguida,
configure os pontos finais do serviço com o serviço de destino na sub-rede que utilizou para a integração. Se então
quisesse aceder a um serviço sobre os pontos finais de serviço:
1. Configure a Integração Regional de VNet com a sua aplicação web
2. ir para o serviço de destino e configurar pontos finais de serviço contra a sub-rede utilizada para a integração
Grupos de segurança de rede
Pode utilizar grupos de segurança de rede para bloquear o tráfego de entrada e saída de recursos num VNet. Uma
aplicação que utiliza a Integração VNet regional pode usar um grupo de segurança de rede para bloquear o tráfego
de saída para recursos no seu VNet ou na internet. Para bloquear o tráfego para endereços públicos, tem de ter a
definição de aplicação WEBSITE_VNET_ROUTE_ALL definida para 1. As regras de entrada num NSG não se aplicam
à sua aplicação porque a Integração VNet afeta apenas o tráfego de saída da sua aplicação.
Para controlar o tráfego de entrada na sua aplicação, utilize a funcionalidade Restrições de Acesso. Um NSG
aplicado à sua sub-rede de integração está em vigor, independentemente de quaisquer rotas aplicadas à sua sub-
rede de integração. Se WEBSITE_VNET_ROUTE_ALL estiver definido para 1 e não tiver rotas que afetem o tráfego de
endereço público na sua sub-rede de integração, todo o tráfego de saída ainda está sujeito a NSGs atribuídos à sua
sub-rede de integração. Se WEBSITE_VNET_ROUTE_ALL não estiver definido, os NSGs são aplicados apenas ao
tráfego RFC1918.
Rotas
Pode utilizar as tabelas de rotas para encaminhar o tráfego de saída da sua app para onde quiser. Por predefinição,
as tabelas de rotas apenas afetam o tráfego de destino RFC1918. Se definir WEBSITE_VNET_ROUTE_ALL para 1,
todas as suas chamadas de saída são afetadas. As rotas que estão definidas na sua sub-rede de integração não
afetarão respostas a pedidos de aplicações de entrada. Os destinos comuns podem incluir dispositivos de firewall
ou gateways.
Se quiser encaminhar todo o tráfego de saída no local, pode utilizar uma mesa de rota para enviar todo o tráfego
de saída para o seu gateway ExpressRoute. Se fizer a rota do tráfego para um gateway, certifique-se de definir rotas
na rede externa para enviar quaisquer respostas de volta.
As rotas do Border Gateway Protocol (BGP) também afetam o tráfego da sua aplicação. Se tiver rotas BGP a partir
de algo como um gateway ExpressRoute, o tráfego de saída da sua aplicação será afetado. Por padrão, as rotas BGP
afetam apenas o tráfego de destino RFC1918. Se WEBSITE_VNET_ROUTE_ALL estiver definido para 1, todo o
tráfego de saída pode ser afetado pelas suas rotas BGP.
Zonas Privadas Azure DNS
Depois de a sua aplicação se integrar com o seu VNet, utiliza o mesmo servidor DNS com o qual o seu VNet está
configurado. Por padrão, a sua aplicação não funcionará com as Zonas Privadas Azure DNS. Para trabalhar com as
Zonas Privadas Azure DNS, é necessário adicionar as seguintes definições de aplicações:
1. WEBSITE_DNS_SERVER com o valor 168.63.129.16
2. WEBSITE_VNET_ROUTE_ALL com o valor 1
Estas definições enviarão todas as suas chamadas de saída da sua app para o seu VNet, além de permitir que a sua
aplicação utilize zonas privadas Azure DNS.
Se quiser fazer chamadas para Private Endpoints,então tem de se integrar com as Zonas Privadas Azure DNS ou
gerir o ponto final privado no servidor DNS utilizado pela sua aplicação.
Como funciona a Integração Regional de VNet
As aplicações no Serviço de Aplicações estão hospedadas em funções de trabalhador. Os planos básicos e de preços
mais elevados são planos de hospedagem dedicados onde não existem cargas de trabalho de outros clientes a
funcionar nos mesmos trabalhadores. A Integração Regional de VNet funciona através da montagem de interfaces
virtuais com endereços na sub-rede delegada. Como o endereço está no seu VNet, pode aceder à maioria das
coisas dentro ou através do seu VNet como um VM no seu VNet. A implementação em rede é diferente de executar
um VM no seu VNet. É por isso que algumas funcionalidades de networking ainda não estão disponíveis para esta
funcionalidade.
Quando a Integração Regional de VNet está ativada, a sua aplicação faz chamadas de saída para a internet através
dos mesmos canais que o normal. Os endereços de saída listados no portal das propriedades da aplicação são os
endereços ainda utilizados pela sua aplicação. O que muda para a sua aplicação são as chamadas para serviços de
serviço seguros de ponto final, ou endereços RFC 1918 vão para o seu VNet. Se WEBSITE_VNET_ROUTE_ALL estiver
definido para 1, todo o tráfego de saída pode ser enviado para o seu VNet.
A funcionalidade suporta apenas uma interface virtual por trabalhador. Uma interface virtual por trabalhador
significa uma Integração VNet regional por plano de Serviço de Aplicação. Todas as aplicações do mesmo plano de
Serviço de Aplicações podem utilizar a mesma Integração VNet. Se precisar de uma aplicação para se ligar a um
VNet adicional, precisa de criar outro plano de Serviço de Aplicações. A interface virtual utilizada não é um recurso
a que os clientes tenham acesso direto.
Devido à natureza do funcionamento desta tecnologia, o tráfego que é usado com a Integração VNet não aparece
nos registos de fluxo da Rede Azure ou NSG.
Integração VNet exigida pelo Gateway

A Integração VNet exigida pelo Gateway suporta a ligação a um VNet noutra região ou a uma rede virtual clássica.
Integração VNet exigida pelo Gateway:
Permite que uma aplicação se conecte a apenas um VNet de cada vez.
Permite a integração de até cinco VNets num plano de Serviço de Aplicações.
Permite que o mesmo VNet seja usado por várias aplicações num plano de Serviço de Aplicações sem afetar o
número total que pode ser usado por um plano de Serviço de Aplicações. Se tiver seis aplicações usando o
mesmo VNet no mesmo plano de Serviço de Aplicações, isso conta como um VNet a ser usado.
Suporta um SLA de 99,9% devido ao SLA no gateway.
Permite que as suas aplicações utilizem o DNS com o qual o VNet está configurado.
Requer um gateway baseado em rede virtual configurado com uma VPN ponto-a-local SSTP antes de poder ser
ligado a uma aplicação.
Não pode utilizar a integração VNet exigida por gateways:
Com um VNet ligado ao Azure ExpressRoute.
De uma aplicação Linux
Para aceder ao ponto final do serviço, recursos seguros.
Com uma porta de entrada de coexistência que suporta tanto o ExpressRoute como as VPNs ponto-a-local ou
site-to-site.
Crie um portal na sua rede virtual Azure
Para criar uma porta de entrada:
1. Crie uma sub-rede de gateway no seu VNet.
2. Crie o gateway VPN. Selecione um tipo VPN baseado em rota.
3. Desaponte os endereços ponto a local. Se o gateway não estiver no SKU básico, então o IKEV2 deve ser
desativado na configuração ponto-a-local e o SSTP deve ser selecionado. O espaço de endereço ponto-a-
local deve estar nos blocos de endereços RFC 1918 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16.
Se criar o portal para utilização com a Integração VNet do Serviço de Aplicações, não precisa de carregar um
certificado. Criar o portal pode demorar 30 minutos. Não poderá integrar a sua aplicação com o seu VNet até que o
gateway seja aprovisionado.
Como funciona a integração VNet exigida por gateways
A Integração VNet exigida pelo Gateway é construída em cima da tecnologia VPN ponto-a-local. As VPNs ponto-a-
local limitam o acesso à rede à máquina virtual que acolhe a aplicação. As aplicações são restritas para enviar
tráfego para a internet apenas através de Conexões Híbridas ou através da Integração VNet. Quando a sua
aplicação está configurada com o portal para utilizar a Integração VNet exigida por gateways, uma negociação
complexa é gerida em seu nome para criar e atribuir certificados no gateway e no lado da aplicação. O resultado é
que os trabalhadores utilizados para hospedar as suas apps são capazes de ligar diretamente ao gateway de rede
virtual no VNet selecionado.
Acesso aos recursos no local

As aplicações podem aceder aos recursos no local, integrando-se com VNets que têm ligações site-to-site. Se
utilizar a Integração VNet exigida por gateways, atualize as suas rotas de gateway VPN no local com os seus blocos
de endereços ponto-a-local. Quando a VPN site-to-site é configurada pela primeira vez, os scripts utilizados para
configurar as rotas devem configurar as rotas corretamente. Se adicionar os endereços ponto-a-local depois de
criar a VPN do site, tem de atualizar as rotas manualmente. Detalhes sobre como fazer isso variam por gateway e
não são descritos aqui. Não pode ter bGP configurado com uma ligação VPN site-to-site.
Não é necessária nenhuma configuração adicional para que a funcionalidade regional de Integração VNet atinja
através do seu VNet para recursos no local. Basta ligar o seu VNet aos recursos no local, utilizando o ExpressRoute
ou uma VPN site-to-site.
NOTE
A funcionalidade de Integração VNet exigida por gateway não integra uma aplicação com um VNet que tenha um gateway
ExpressRoute. Mesmo que o gateway ExpressRoute esteja configurado em modo de coexistência,a Integração VNet não
funciona. Se precisar de aceder aos recursos através de uma ligação ExpressRoute, utilize a funcionalidade regional de
Integração VNet ou um Ambiente de Serviço de Aplicações, que funciona no seu VNet.
Peering
Se utilizar o seu olhar com a Integração Regional de VNet, não precisa de fazer nenhuma configuração adicional.
Se utilizar a Integração VNet exigida por gateways com o seu espremia, tem de configurar alguns itens adicionais.
Para configurar olhando para trabalhar com a sua aplicação:
1. Adicione uma ligação de espreitar no VNet a que a sua aplicação se conecta. Ao adicionar a ligação de pares,
ative o acesso à rede vir tual e selecione Deixe o tráfego reencaminhado e permita o trânsito de
gateway .
2. Adicione uma ligação de observação no VNet que está a ser espreitada para o VNet a que está ligado. Quando
adicionar a ligação de espreitamento no destino VNet, ative o acesso à rede vir tual e selecione Deixe o
tráfego reencaminhado e permita gateways remotos .
3. Aceda ao plano de Ser viço de > Aplicações networking > VNet Integration UI no portal. Selecione o VNet
a que a sua aplicação se conecta. Na secção de encaminhamento, adicione o intervalo de endereços do VNet que
está espreguiçadado com o VNet a que a sua aplicação está ligada.
Gerir a integração vNet

A ligação e desconexão com um VNet encontra-se ao nível da aplicação. As operações que podem afetar a
integração do VNet em várias aplicações estão ao nível do plano do Serviço de Aplicações. A partir da aplicação >
portal de > Integração VNet em rede, pode obter detalhes sobre o seu VNet. Pode ver informações semelhantes
ao nível do plano do Serviço de Aplicações no portal de Integração VNet do plano de serviço de > Networking >
VNet Integration aplicações.
A única operação que pode ter na visão da aplicação da sua instância de Integração VNet é desligar a sua aplicação
do VNet a que está atualmente ligada. Para desligar a sua aplicação de um VNet, selecione Disconnect . A sua
aplicação é reiniciada quando desliga de um VNet. Desligar não muda o seu VNet. A sub-rede ou gateway não é
removida. Se quiser então eliminar o seu VNet, desligue primeiro a sua aplicação do VNet e elimine os recursos
nele, como os gateways.
O plano de Serviço de Aplicações VNet Integration UI mostra-lhe todas as integrações VNet utilizadas pelas
aplicações no seu plano de Serviço de Aplicações. Para ver detalhes em cada VNet, selecione o VNet em que está
interessado. Existem duas ações que pode realizar aqui para integração VNet exigida por gateway:
Rede sincronizada : A operação de rede de sincronização é utilizada apenas para a função de Integração VNet
dependente de gateways. A realização de uma operação de rede de sincronização garante que os seus
certificados e informações de rede estão sincronizados. Se adicionar ou alterar o DNS do seu VNet, efetue uma
operação de rede de sincronização. Esta operação reinicia quaisquer aplicações que utilizem este VNet. Esta
operação não funcionará se estiver a utilizar uma app e um vnet pertencentes a diferentes subscrições.
Adicionar rotas : Adicionar rotas conduz o tráfego de saída para o seu VNet.
Encaminhamento de integração VNet exigido pela Porta de entrada
As rotas definidas no seu VNet são usadas para direcionar o tráfego para o seu VNet a partir da sua aplicação. Para
enviar tráfego adicional de saída para o VNet, adicione os blocos de endereços aqui. Esta capacidade funciona
apenas com a integração VNet exigida por gateways. As tabelas de rotas não afetam o tráfego da sua aplicação
quando utiliza a Integração VNet exigida pelo gateway da forma que fazem com a Integração Regional de VNet.
Certificados de integração VNet exigidos pelo Gateway
Quando a integração VNet exigida pelo gateway está ativada, há uma troca obrigatória de certificados para garantir
a segurança da ligação. Juntamente com os certificados estão a configuração de DNS, rotas e outras coisas
semelhantes que descrevem a rede.
Se os certificados ou informações de rede forem alterados, selecione Sync Network . Quando seleciona a Sync
Network , causa uma breve interrupção na conectividade entre a sua aplicação e o seu VNet. Embora a sua
aplicação não seja reiniciada, a perda de conectividade pode fazer com que o seu site não funcione corretamente.
Detalhes dos preços

A funcionalidade regional de Integração VNet não tem qualquer custo adicional para utilização para além dos
custos de preços do plano de preços do App Service.
Três encargos estão relacionados com a utilização da funcionalidade de Integração VNet exigida por gateway:
Taxas de preços do plano app : As suas aplicações precisam de estar num plano de Serviço de Aplicações
Standard, Premium ou PremiumV2. Para obter mais informações sobre estes custos, consulte os preços do
Custos de transferência de dados : Há um custo para a saída de dados, mesmo que o VNet esteja no mesmo
centro de dados. Estes encargos são descritos em detalhes de preços de transferência de dados.
Custos de gateway VPN : Há um custo para o gateway de rede virtual que é necessário para a VPN ponto-a-
local. Para obter mais informações, consulte os preços da porta de entrada VPN.
A funcionalidade é fácil de configurar, mas isso não significa que a sua experiência será livre de problemas. Se
encontrar problemas de acesso ao ponto final pretendido, existem alguns utilitários que pode utilizar para testar a
conectividade a partir da consola de aplicações. Há duas consolas que podes usar. Uma é a consola Kudu, e a outra
é a consola no portal Azure. Para chegar à consola Kudu a partir da sua aplicação, vá a Tools > Kudu . Você também
pode chegar à consola Kudo em [sitename].scm.azurewebsites.net. Depois de o site carregar, vá ao separador de
consola Debug. Para chegar à consola azure hospedada pelo portal a partir da sua aplicação, vá para tools >
console .
Ferramentas
As ferramentas ping , nslookup , e tracer t não funcionarão através da consola devido a restrições de segurança.
Para preencher o vazio, são adicionadas duas ferramentas separadas. Para testar a funcionalidade DNS,
adicionámos uma ferramenta chamada nameresolver.exe . A sintaxe é:
nameresolver.exe hostname [optional: DNS Server]
Pode utilizar nameresolver para verificar os nomes de anfitriões de que a sua aplicação depende. Desta forma, pode
testar se tem algo mal configurado com o seu DNS ou talvez não tenha acesso ao seu servidor DNS. Pode ver o
servidor DNS que a sua aplicação utiliza na consola olhando para as variáveis ambientais WEBSITE_DNS_SERVER e
WEBSITE_DNS_ALT_SERVER.
Pode utilizar a ferramenta seguinte para testar a conectividade TCP com uma combinação de hospedeiro e porta.
Esta ferramenta chama-se tcpping e a sintaxe é:
tcpping.exe hostname [optional: port]
O utilitário tcpping diz-lhe se pode chegar a um hospedeiro específico e porto. Só pode mostrar sucesso se houver
uma aplicação a ouvir a combinação de anfitriões e portas, e há acesso de rede da sua app ao anfitrião especificado
e à porta.
Depuração de acesso a recursos de rede virtuais hospedados em rede
Várias coisas podem impedir que a sua aplicação chegue a um anfitrião específico e à porta. A maior parte do
tempo é uma destas coisas:
Uma firewall está no caminho. Se tiver uma firewall no caminho, atinja o intervalo do TCP. O tempo de saída
do TCP é de 21 segundos neste caso. Utilize a ferramenta de tcpping para testar a conectividade. Os intervalos
de tCP podem ser causados por muitas coisas além das firewalls, mas comecem por aí.
DNS não é acessível. O tempo de saída do DNS é de 3 segundos por servidor DNS. Se tiver dois servidores
DNS, o tempo é de 6 segundos. Use nameresolver para ver se o DNS está funcionando. Não pode usar o
nslookup, porque isso não usa o DNS com o qual a sua rede virtual está configurada. Se não for acessível, pode
ter uma firewall ou NSG bloqueando o acesso ao DNS ou pode estar em baixo.
Se esses itens não responderem aos seus problemas, procure primeiro coisas como:
O seu destino é um endereço não RFC1918 e não tem WEBSITE_VNET_ROUTE_ALL definido para 1?
Existe algum nSG bloqueando a saída da sua subnet de integração?
Se estiver a atravessar o Azure ExpressRoute ou uma VPN, o seu portal no local está configurado para
encaminhar o tráfego de volta para Azure? Se conseguir chegar a pontos finais na sua rede virtual, mas não no
local, verifique as suas rotas.
Tem permissão suficiente para definir delegação na subnet de integração? Durante a configuração regional de
Integração VNet, a sua subnet de integração é delegada na Microsoft.Web. O VNet Integration UI delega a
subnet para Microsoft.Web automaticamente. Se a sua conta não tiver permissões de networking suficientes
para definir a delegação, precisará de alguém que possa definir atributos na sua subnet de integração para
delegar a subnet. Para delegar manualmente a subnet de integração, vá à subnet UI da rede virtual Azure e
desloque a delegação para microsoft.Web.
Integração VNet exigida por gateway
O intervalo de endereços ponto-a-local nas gamas RFC 1918 (10.0.0.0.0.0-10.255.255.255 / 172.16.0.0-
172.31.255.255 / 192.168.0-192.168.255.255)?
O portal mostra como estando no portal? Se o seu portal está para baixo, então traga-o de volta para cima.
Os certificados mostram estar sincronizado, ou suspeita que a configuração da rede foi alterada? Se os seus
certificados estiverem dessincronizados ou suspeitar que foi feita uma alteração na configuração da sua rede
virtual que não foi sincronizada com os seus ASPs, selecione Sync Network .
Se estiver a atravessar uma VPN, a porta de entrada no local está configurada para encaminhar o tráfego de
volta para Azure? Se conseguir chegar a pontos finais na sua rede virtual, mas não no local, verifique as suas
rotas.
Está a tentar usar um portal de coexistência que suporta tanto o ponto de ponta como o ExpressRoute? Os
gateways de coexistência não são suportados com a Integração VNet.
Depurar problemas de networking é um desafio porque você não pode ver o que está bloqueando o acesso a uma
combinação específica de hospedeiro:porta. Algumas causas incluem:
Tem uma firewall no seu anfitrião que impede o acesso à porta de aplicação a partir da sua gama IP ponto-a-
local. A travessia das subredes requer frequentemente acesso público.
O seu anfitrião alvo está abatido.
A sua candidatura está em baixo.
Tinhao IP errado ou nome de anfitrião.
A sua aplicação está a ouvir num porto diferente do que esperava. Pode comparar o seu ID de processo com a
porta de audição utilizando "netstat -aon" no hospedeiro final.
Os seus grupos de segurança de rede estão configurados de forma a impedir o acesso ao seu anfitrião de
aplicação e porta a partir da sua gama IP ponto-a-local.
Não sabe qual o endereço que a sua aplicação realmente usa. Pode ser qualquer endereço na subnet de integração
ou no intervalo de endereços ponto-a-local, por isso precisa de permitir o acesso a partir de toda a gama de
endereços.
Os passos adicionais de depuração incluem:
Ligue-se a um VM na sua rede virtual e tente chegar ao seu anfitrião de recursos:porta a partir daí. Para
testar o acesso à TCP, utilize a ligação de teste de comando PowerShell . A sintaxe é:
test-netconnection hostname [optional: -Port]
Traga uma aplicação num VM e teste o acesso a esse anfitrião e à porta a partir da consola através da
utilização de tcpping .
Recursos no local
Se a sua aplicação não conseguir contactar um recurso no local, verifique se consegue contactar o recurso da sua
rede virtual. Utilize o comando PowerShell de ligação de rede de teste para verificar se há acesso tCP. Se o seu
VM não conseguir contactar o seu recurso no local, a sua ligação VPN ou ExpressRoute pode não estar configurada
corretamente.
Se o seu VM virtual hospedado em rede pode chegar ao seu sistema no local, mas a sua aplicação não pode, a
causa é provavelmente uma das seguintes razões:
As suas rotas não estão configuradas com a sua subnet ou intervalos de endereços ponto-a-local no seu
gateway no local.
Os seus grupos de segurança de rede estão a bloquear o acesso à sua gama IP ponto-a-site.
As suas firewalls no local estão a bloquear o tráfego da sua gama IP ponto-a-local.
Está a tentar chegar a um endereço não RFC 1918 utilizando a funcionalidade regional de Integração VNet.
Automatização
O suporte CLI está disponível para integração regional de VNet. Para aceder aos seguintes comandos, instale o
Azure CLI.
az webapp vnet-integration --help
Group
az webapp vnet-integration : Methods that list, add, and remove virtual network integrations
from a webapp.
This command group is in preview. It may be changed/removed in a future release.
Commands:
add : Add a regional virtual network integration to a webapp.
list : List the virtual network integrations on a webapp.
remove : Remove a regional virtual network integration from webapp.
az appservice vnet-integration --help
Group
az appservice vnet-integration : A method that lists the virtual network integrations used in an
appservice plan.
Commands:
list : List the virtual network integrations used in an appservice plan.
Para a integração VNet exigida por gateways, pode integrar o Serviço de Aplicações com uma rede virtual Azure
utilizando o PowerShell. Para um script pronto a executar, consulte uma aplicação no Azure App Service a uma rede
virtual Azure.
Conexões híbridas do serviço de aplicações Azure
Hybrid Connections é simultaneamente um serviço no Azure e uma funcionalidade no Azure App Service. Como
serviço, tem utilizações e capacidades para além daquelas que são usadas no Serviço de Aplicações. Para saber
mais sobre conexões híbridas e a sua utilização fora do Serviço de Aplicações, consulte as Ligações Híbridas
Azure Relay.
Dentro do Serviço de Aplicações, as Ligações Híbridas podem ser usadas para aceder a recursos de aplicações
em qualquer rede que possa fazer chamadas de saída para a Azure sobre a porta 443. A Hybrid Connections
fornece acesso da sua app a um ponto final TCP e não permite uma nova forma de aceder à sua aplicação. Como
usado no Serviço de Aplicações, cada Ligação Híbrida está relacionada com um único hospedeiro TCP e
combinação de porta. Isto permite que as suas aplicações acedam a recursos em qualquer SISTEMA, desde que
seja um ponto final TCP. A funcionalidade Ligações Híbridas não sabe nem se importa com o protocolo de
aplicação ou com o que está a aceder. Simplesmente fornece acesso à rede.
Como funciona
As Ligações Híbridas requerem que seja implantado um agente de retransmissão onde possa atingir tanto o
ponto final pretendido como o Azure. O agente de retransmissão, Hybrid Connection Manager (HCM), chama a
Azure Relay sobre a porta 443. A partir do site de aplicações, a infraestrutura do Serviço de Aplicações também
se conecta ao Azure Relay em nome da sua aplicação. Através das ligações juntas, a sua aplicação é capaz de
aceder ao ponto final pretendido. A ligação utiliza as chaves TLS 1.2 para segurança e assinatura de acesso
partilhado (SAS) para autenticação e autorização.
Quando a sua aplicação fizer um pedido de DNS que corresponda a um ponto final de ligação híbrido
configurado, o tráfego TCP de saída será redirecionado através da Ligação Híbrida.
NOTE
Isto significa que deve tentar sempre usar um nome DNS para a sua Ligação Híbrida. Alguns softwares de clientes não
fazem uma procura de DNS se o ponto final utilizar um endereço IP.
Benefícios de conexão híbrida do serviço de aplicações

Existem vários benefícios para a capacidade de conexões híbridas, incluindo:
As aplicações podem aceder em segurança aos sistemas e serviços no local.
A funcionalidade não requer um ponto final acessível à Internet.
É rápido e fácil de configurar. Não são necessários portais
Cada Ligação Híbrida corresponde a uma única combinação de anfitrião:porta, útil para a segurança.
Normalmente não requer buracos de firewall. As ligações são todas de saída sobre portas web padrão.
Como a funcionalidade é de rede, é agnóstico ao idioma utilizado pela sua app e à tecnologia utilizada pelo
ponto final.
Pode ser usado para fornecer acesso em várias redes a partir de uma única aplicação.
É suportado em GA para aplicações windows e está em pré-visualização para aplicações Linux.
Coisas que não pode fazer com ligações híbridas
As coisas que não pode fazer com ligações híbridas incluem:
Monte uma unidade.
Use UDP.
Aceda a serviços baseados em TCP que utilizem portas dinâmicas, como o Modo Passivo FTP ou o Modo
Passivo Alargado.
Apoiar lDAP, porque pode requerer UDP.
Suporte Ative Directory, porque não pode fazer o domínio de um trabalhador do Serviço de Aplicações.
Adicione e crie conexões híbridas na sua aplicação

Para criar uma Ligação Híbrida, vá ao portal Azure e selecione a sua aplicação. Selecione Configurar a rede >
configurar os seus pontos finais de ligação híbrida . Aqui pode ver as Conexões Híbridas que estão
configuradas para a sua aplicação.
Para adicionar uma nova Ligação Híbrida, selecione [+] Adicionar ligação híbrida . Verá uma lista das Ligações
Híbridas que já criou. Para adicionar um ou mais deles à sua aplicação, selecione as que pretende e, em seguida,
selecione Adicionar a Ligação Híbrida selecionada .
Se pretender criar uma nova Ligação Híbrida, selecione Criar uma nova ligação híbrida . Especificar:
Nome de ligação híbrida.
Nome de anfitrião de ponto final.
Porta de ponto final.
Serviço Espaço de nomes de ônibus que você deseja usar.
Cada Conexão Híbrida está ligada a um espaço de nomes de ônibus de serviço, e cada espaço de nome de
Service Bus está numa região de Azure. É importante tentar usar um espaço de nome de Service Bus na mesma
região que a sua aplicação, para evitar a latência induzida pela rede.
Se pretender remover a sua Ligação Híbrida da sua aplicação, clique com o botão direito e selecione
Disconnect .
Quando uma Ligação Híbrida é adicionada à sua aplicação, pode ver detalhes sobre ela simplesmente
selecionando-o.
Criar uma ligação híbrida no portal Azure Relay

Além da experiência do portal dentro da sua app, pode criar Conexões Híbridas a partir do portal Azure Relay.
Para que uma ligação híbrida seja utilizada pelo Serviço de Aplicações, deve:
Requer autorização do cliente.
Tenha um item de metadados, nomeado ponto final, que contenha uma combinação host:port como o valor.
Conexões Híbridas e planos de Serviço de Aplicações

As conexões híbridas do Serviço de Aplicações só estão disponíveis em SKUs de preços básicos, standard,
premium e isolados. Há limites ligados ao plano de preços.
P L A N O DE P REÇ O S N ÚM ERO DE L IGA Ç Õ ES H ÍB RIDA S UT IL IZ ÁVEIS N O P L A N O
Básica 5 por plano
Standard 25 por plano

P L A N O DE P REÇ O S N ÚM ERO DE L IGA Ç Õ ES H ÍB RIDA S UT IL IZ ÁVEIS N O P L A N O
PremiumV2 200 por app
Isolado 200 por app
O plano de Serviço de Aplicações UI mostra-lhe quantas Ligações Híbridas estão a ser usadas e por que
aplicações.
Selecione a Ligação Híbrida para ver detalhes. Pode ver toda a informação que viu na vista da aplicação. Também
pode ver quantas outras aplicações no mesmo plano estão a usar essa Ligação Híbrida.
Existe um limite para o número de pontos finais de Conexão Híbrida que podem ser usados num plano de
Serviço de Aplicações. Cada Ligação Híbrida utilizada, no entanto, pode ser usada em qualquer número de
aplicações nesse plano. Por exemplo, uma única Ligação Híbrida que é usada em cinco aplicações separadas num
plano de Serviço de Aplicações conta como uma Ligação Híbrida.
Preços
Além de existir um requisito de SKU do plano de serviço de aplicações, existe um custo adicional para a utilização
de Conexões Híbridas. Há uma taxa para cada ouvinte usado por uma Ligação Híbrida. O ouvinte é o Gestor de
Ligação Híbrida. Se tivesses cinco Conexões Híbridas apoiadas por dois Gestores de Conexão Híbrida, seriam 10
ouvintes. Para mais informações, consulte os preços do Service Bus.
Gestor de Conexão Híbrida

A função Ligações Híbridas requer um agente de retransmissão na rede que hospeda o seu ponto de terminação
de Ligação Híbrida. Este agente de retransmissão chama-se Gestor de Ligação Híbrida (HCM). Para baixar o HCM,
a partir da sua aplicação no portal Azure,selecione Networking > Configure seus pontos finais de Ligação
Híbrida .
Esta ferramenta é executado no Windows Server 2012 e posteriormente. O HCM funciona como um serviço e
liga a saída ao Azure Relay na porta 443.
Depois de instalar o HCM, pode executar HybridConnectionManagerUi.exe para utilizar a UI para a ferramenta.
Este ficheiro está no diretório de instalação do Hybrid Connection Manager. No Windows 10, também pode
pesquisar o UI do Gestor de Conexões Híbridos na sua caixa de pesquisa.
Quando inicia o HCM UI, a primeira coisa que vê é uma tabela que lista todas as Conexões Híbridas que estão
configuradas com este caso do HCM. Se quiser es alterar, autente primeiro com o Azure.
Para adicionar uma ou mais ligações híbridas ao seu HCM:
1. Inicie a UI HCM.
2. Selecione Configurar outra Ligação Híbrida .
3. Faça sô-9 com a sua conta Azure para obter as suas Ligações Híbridas disponíveis com as suas
subscrições. O HCM não continua a utilizar a sua conta Azure para além disso.
4. Escolha uma subscrição.
5. Selecione as Ligações Híbridas que pretende que o HCM retransmite.
Agora pode ver as Ligações Híbridas que adicionou. Também pode selecionar a Ligação Híbrida configurada para
ver detalhes.
Para suportar as Ligações Híbridas com as qual está configurado, o HCM requer:
Acesso TCP a Azure sobre a porta 443.
Acesso TCP ao ponto final de ligação híbrida.
A capacidade de fazer pesquisas DNS no anfitrião do ponto final e no espaço de nomes do Service Bus.
NOTE
O Azure Relay conta com tomadas web para conectividade. Esta capacidade só está disponível no Windows Server 2012
ou posteriormente. Por isso, o HCM não é suportado em nada mais cedo do que o Windows Server 2012.
Redundância
Cada HCM pode suportar várias Ligações Híbridas. Além disso, qualquer ligação híbrida dada pode ser
suportada por vários HCMs. O comportamento padrão é encaminhar o tráfego através dos HCMs configurados
para qualquer ponto final. Se pretender uma elevada disponibilidade nas suas Ligações Híbridas a partir da sua
rede, execute vários HCMs em máquinas separadas. O algoritmo de distribuição de carga utilizado pelo serviço
Relay para distribuir tráfego aos HCMs é uma atribuição aleatória.
Adicione manualmente uma ligação híbrida
Para permitir que alguém fora da sua subscrição apresente uma instância HCM para uma determinada Ligação
Híbrida, partilhe com eles a cadeia de ligação gateway para a Ligação Híbrida. Pode ver a cadeia de ligação
gateway nas propriedades de Conexão Híbrida no portal Azure. Para utilizar esta corda, selecione Introduza
manualmente no HCM e cole na cadeia de ligação gateway.
Atualizar
Existem atualizações periódicas ao Gestor de Ligação Híbrida para corrigir problemas ou fornecer melhorias.
Quando as atualizações forem lançadas, um pop-up aparecerá na UI HCM. A aplicação da atualização aplicará as
alterações e reiniciará o HCM.
Adicionar uma Ligação Híbrida à sua aplicação programáticamente

Existe suporte Azure CLI para ligações híbridas. Os comandos fornecidos funcionam tanto a nível da aplicação
como do plano do Serviço de Aplicações. Os comandos de nível de aplicação são:
az webapp hybrid-connection
Group
az webapp hybrid-connection : Methods that list, add and remove hybrid-connections from webapps.
Commands:
add : Add a hybrid-connection to a webapp.
list : List the hybrid-connections on a webapp.
remove : Remove a hybrid-connection from a webapp.
Os comandos do plano de serviço de aplicações permitem definir qual a chave que uma determinada ligação
híbrida irá utilizar. Há duas teclas definidas em cada Ligação Híbrida, uma primária e uma secundária. Pode optar
por utilizar a tecla primária ou secundária com os comandos abaixo. Isto permite-lhe trocar as teclas para
quando pretender regenerar periodicamente as suas chaves.
az appservice hybrid-connection --help
Group
az appservice hybrid-connection : A method that sets the key a hybrid-connection uses.
Commands:
set-key : Set the key that all apps in an appservice plan use to connect to the hybrid-
connections in that appservice plan.
Proteja as suas ligações híbridas

Uma conexão híbrida existente pode ser adicionada a outras Aplicações Web do Serviço de Aplicações por
qualquer utilizador que tenha permissões suficientes no Relé de autocarros do Serviço Azure subjacente. Isto
significa que, se tiver de impedir que outros reune a mesma Ligação Híbrida (por exemplo, quando o recurso-
alvo é um serviço que não dispõe de medidas de segurança adicionais para impedir o acesso não autorizado),
deve bloquear o acesso ao Relé de Autocarros do Serviço Azure.
Qualquer pessoa que tenha Reader acesso ao Relé poderá ver a Ligação Híbrida ao tentar adicioná-la à sua Web
App no portal Azure, mas não poderá adicioná-la, uma vez que não tem as permissões necessárias para
recuperar a cadeia de ligação que é utilizada para estabelecer a ligação de retransmissão. Para poderem
adicionar com sucesso a Ligação Híbrida, devem ter a listKeys permissão (
Microsoft.Relay/namespaces/hybridConnections/authorizationRules/listKeys/action ). O Contributor papel ou
qualquer outra função que inclua esta permissão no Relé permitirá que os utilizadores utilizem a Conexão
Híbrida e adicionem-na às suas próprias Aplicações Web.
O estado de "Conectado" significa que pelo menos um HCM está configurado com essa Ligação Híbrida, e é
capaz de chegar a Azure. Se o estado da sua Ligação Híbrida não disser Conectado, a sua Ligação Híbrida não
está configurada em nenhum HCM que tenha acesso ao Azure.
A principal razão pela qual os clientes não podem ligar-se ao seu ponto final é porque o ponto final foi
especificado usando um endereço IP em vez de um nome DNS. Se a sua aplicação não conseguir alcançar o
ponto final pretendido e utilizar um endereço IP, mude para usar um nome DNS válido no anfitrião onde o HCM
está em execução. Verifique também se o nome DNS se resolve corretamente no hospedeiro onde o HCM está
em funcionamento. Confirme que existe conectividade do hospedeiro onde o HCM está a correr até ao ponto
final de ligação híbrida.
No Serviço de Aplicações, a ferramenta da linha de comando tcpping pode ser invocada a partir da consola
Advanced Tools (Kudu). Esta ferramenta pode dizer-lhe se tem acesso a um ponto final TCP, mas não lhe diz se
tem acesso a um ponto final de Ligação Híbrida. Quando utilizar a ferramenta na consola contra um ponto final
de ligação híbrida, está apenas a confirmar que utiliza uma combinação host:porta.
Se tiver um cliente de linha de comando para o seu ponto final, pode testar a conectividade a partir da consola
de aplicações. Por exemplo, pode testar o acesso aos pontos finais do servidor web utilizando o curl.
Controlar o tráfego do Serviço de Aplicações Azure
com o Gestor de Tráfego Azure
NOTE
Este artigo fornece informações sumárias para o Microsoft Azure Traffic Manager no que diz respeito ao Serviço de Aplicações
Azure. Mais informações sobre o próprio Gestor de Tráfego do Azure podem ser encontradas visitando os links no final deste
artigo.
Introdução
Pode utilizar o Gestor de Tráfego do Azure para controlar como os pedidos de clientes Web são distribuídos para as
aplicações no Serviço de Aplicações do Azure. Quando os pontos finais do Serviço de Aplicações são adicionados a
um perfil do Gestor de Tráfego do Azure, o Gestor de Tráfego do Azure mantém um registo do estado das suas
aplicações do Serviço de Aplicações (em execução, parado ou eliminado), para que possa decidir quais desses
pontos finais deve receber tráfego.
Métodos de encaminhamento
O Azure Traffic Manager utiliza quatro métodos de encaminhamento diferentes. Estes métodos são descritos na
seguinte lista, uma vez que dizem respeito ao Serviço de Aplicações Azure.
** Prioridade:** utilize uma aplicação primária para todo o tráfego e forneça cópias de segurança caso as
principais ou as aplicações de backup não estejam disponíveis.
** Ponderado:** distribua o tráfego através de um conjunto de aplicações, uniformemente ou de acordo com os
pesos, que define.
** Desempenho:** quando tiver aplicações em diferentes locais geográficos, utilize a aplicação "mais próxima"
em termos da menor latência da rede.
** Geographic:** utilizadores direcionados para aplicações específicas com base na localização geográfica de
onde provém a sua consulta de DNS.
Para mais informações, consulte os métodos de encaminhamento do Gestor de Tráfego.
Perfis de Serviço de Aplicativos e Gestor de Tráfego

Para configurar o controlo do tráfego de aplicações do App Service, cria um perfil no Gestor de Tráfego Azure que
utiliza um dos quatro métodos de equilíbrio de carga descritos anteriormente e, em seguida, adicione os pontos
finais (neste caso, App Service) para os quais pretende controlar o tráfego no perfil. O estado da sua aplicação (em
execução, paragem ou eliminado) é regularmente comunicado ao perfil para que o Gestor de Tráfego Azure possa
direcionar o tráfego em conformidade.
Ao utilizar o Gestor de Tráfego Azure com o Azure, tenha em mente os seguintes pontos:
Para implementações de aplicações apenas dentro da mesma região, o App Service já fornece funcionalidade
sinuosa e rodada sem ter em conta o modo de aplicação.
Para implementações na mesma região que utilizam o App Service em conjunto com outro serviço de nuvem
Azure, pode combinar ambos os tipos de pontos finais para permitir cenários híbridos.
Só é possível especificar um ponto final do Serviço app por região num perfil. Quando seleciona uma aplicação
como ponto final para uma região, as restantes aplicações nessa região tornam-se indisponíveis para seleção
para esse perfil.
Os pontos finais do Serviço de Aplicações que especifica num perfil do Gestor de Tráfego Azure aparecem na
secção Nomes de Domínio na página Configure para a aplicação no perfil, mas não é configurável lá.
Depois de adicionar uma aplicação a um perfil, o URL do Site no Dashboard da página do portal da aplicação
exibe o URL de domínio personalizado da aplicação se tiver configurado uma. Caso contrário, exibe o URL de
perfil contoso.trafficmanager.net do Gestor de Tráfego (por exemplo, ). Tanto o nome de domínio direto da
aplicação como o URL do Gestor de Tráfego estão visíveis na página configure da aplicação na secção Nomes de
Domínio.
Os seus nomes de domínio personalizados funcionam como esperado, mas além de adicioná-los às suas
aplicações, também deve configurar o seu mapa DNS para apontar para o URL do Gestor de Tráfego. Para obter
informações sobre como configurar um domínio personalizado para uma aplicação de Serviço de Aplicações,
consulte Configurar um nome de domínio personalizado no Serviço de Aplicações Azure com integração do
Traffic Manager.
Só pode adicionar aplicações que estejam em modo standard ou premium a um perfil do Gestor de Tráfego Do
Azure.
Adicionar uma aplicação a um perfil do Traffic Manager faz com que a aplicação seja reiniciada.
Passos Seguintes
Para uma visão geral conceptual e técnica do Gestor de Tráfego Azure, consulte a visão geral do Gestor de Tráfego.
Visão geral do Cache Local do Serviço de Aplicações
Azure
NOTE
A cache local não é suportada em aplicações de função ou aplicações de Serviço de Aplicações contentorizadas, como em
Recipientes Windows ou no Serviço de Aplicações no Linux.
O conteúdo do Serviço de Aplicações Azure é armazenado no Armazenamento Azure e é emergido de forma

durável como uma partilha de conteúdo. Este design destina-se a trabalhar com uma variedade de apps e tem os
seguintes atributos:
O conteúdo é partilhado em várias instâncias de máquina virtual (VM) da aplicação.
O conteúdo é durável e pode ser modificado através da execução de apps.
Os ficheiros de registo e os ficheiros de dados de diagnóstico estão disponíveis na mesma pasta de conteúdo
partilhado.
A publicação de novos conteúdos atualiza diretamente a pasta de conteúdos. Pode visualizar imediatamente o
mesmo conteúdo através do website SCM e da aplicação de execução (normalmente algumas tecnologias
como ASP.NET iniciar um reinício de aplicação em algumas alterações de ficheiros para obter os conteúdos
mais recentes).
Apesar de muitas aplicações utilizarem uma ou todas estas funcionalidades, algumas aplicações apenas precisam
de uma loja de conteúdos de alto desempenho, apenas de leitura, da qual podem funcionar com elevada
disponibilidade. Estas aplicações podem beneficiar de uma instância VM de uma cache local específica.
A funcionalidade Cache Local do Serviço de Aplicações Azure proporciona uma visão de papel web dos seus
conteúdos. Este conteúdo é uma cache de escrita mas descartar o seu conteúdo de armazenamento que é criado
assincronicamente no local. Quando a cache estiver pronta, o site é trocado para ser executado contra o conteúdo
em cache. As aplicações que funcionam em Cache Local têm os seguintes benefícios:
São imunes às tardios que ocorrem quando acedem ao conteúdo no Armazenamento Azure.
São imunes às atualizações planeadas ou aos tempos de paragem não planeados e a quaisquer outras
perturbações com o Armazenamento Azure que ocorram em servidores que servem a partilha de conteúdos.
Têm menos reinícios de aplicações devido a alterações nas ações de armazenamento.
Como a cache local muda o comportamento do Serviço de Aplicações

D:\home aponta para a cache local, que é criada na instância VM quando a aplicação começa. D:\local continua
a apontar para o armazenamento temporário em VM-specific.
A cache local contém uma cópia única das pastas /site e/extensões do site da loja de conteúdos partilhados,
em D:\home\site e extensões de site D:\home, respectivamente. Os ficheiros são copiados para a cache local
quando a aplicação começa. O tamanho das duas pastas para cada aplicação está limitado a 1 GB por padrão,
mas pode ser aumentado para 2 GB. Note que à medida que o tamanho da cache aumenta, levará mais tempo
para carregar a cache. Se os ficheiros copiados excederem o tamanho da cache local, o Serviço de Aplicações
ignora silenciosamente a cache local e lê-se a partir da partilha remota de ficheiros.
A cache local é leitura-escrita. No entanto, qualquer modificação é descartada quando a aplicação move
máquinas virtuais ou é reiniciada. Não utilize o cache local para apps que armazenem dados críticos de missão
na loja de conteúdos.
D:\home\LogFiles e D:\home\Dados contêm ficheiros de registo e dados de aplicações. As duas subpastas são
armazenadas localmente na instância VM, e são copiadas periodicamente para a loja de conteúdos partilhados.
As aplicações podem persistir ficheiros de registo e dados escrevendo-os para estas pastas. No entanto, a
cópia para a loja de conteúdos partilhados é o melhor esforço, pelo que é possível que os ficheiros de registo e
os dados sejam perdidos devido a uma queda repentina de uma instância VM.
O streaming de registo supor-se na cópia do melhor esforço. Pode observar até um minuto de atraso nos
registos transmitidos.
Na loja de conteúdos partilhados, existe uma alteração na estrutura da pasta das pastas LogFiles e Data para
aplicações que utilizam o cache local. Existem agora subpastas nelas que seguem o padrão de nomeação de
"identificador único" + carimbo de tempo. Cada uma das subpastas corresponde a um caso VM em que a
aplicação está em execução ou está a funcionar.
Outras pastas em D:\home permanecem na cache local e não são copiadas para a loja de conteúdos
partilhados.
A implementação da aplicação através de qualquer método suportado publica diretamente na loja de
conteúdos partilhados duráveis. Para refrescar as pastas d:\home\site e d:\home\siteextensions na cache local,
a aplicação precisa de ser reiniciada. Para tornar o ciclo de vida perfeito, consulte a informação mais tarde
neste artigo.
A visão predefinida do conteúdo do site SCM continua a ser a da loja de conteúdos partilhados.
Ativar cache local no serviço de aplicações

Configura o Cache Local utilizando uma combinação de definições de aplicações reservadas. Pode configurar
estas definições de aplicações utilizando os seguintes métodos:
Portal do Azure
Azure Resource Manager
Configure cache local utilizando o portal Azure
Você ativa o Cache Local numa base por web-app usando esta definição de aplicação: WEBSITE_LOCAL_CACHE_OPTION
= Always
Configure a cache local utilizando o Gestor de Recursos Azure

...
{
"apiVersion": "2015-08-01",
"type": "config",
"name": "appsettings",
"dependsOn": [
"[resourceId('Microsoft.Web/sites/', variables('siteName'))]"
],
"properties": {
"WEBSITE_LOCAL_CACHE_OPTION": "Always",
"WEBSITE_LOCAL_CACHE_SIZEINMB": "1000"
}
}
...
Alterar a definição de tamanho em Cache Local

Por padrão, o tamanho da cache local é de 1 GB . Isto inclui as pastas /site e/siteextensions que são copiadas da
loja de conteúdos, bem como quaisquer registos e pastas de dados criadas localmente. Para aumentar este limite,
WEBSITE_LOCAL_CACHE_SIZEINMB utilize a definição da aplicação . Pode aumentar o tamanho até 2 GB (2000 MB) por
app. Note que levará mais tempo para carregar a cache local à medida que o tamanho aumenta.
Boas práticas para usar o Cache Local do Serviço de Aplicações

Recomendamos que utilize cache local em conjunto com a funcionalidade Ambientes de Encenação.
Adicione a WEBSITE_LOCAL_CACHE_OPTION definição de Always aplicação pegajosa com o valor à sua ranhura de
Produção. Se estiver a WEBSITE_LOCAL_CACHE_SIZEINMB utilizar, adicione-o também como uma definição
pegajosa à sua ranhura de Produção.
Crie uma ranhura de Encenação e publique na sua slot de encenação. Normalmente, não se define a ranhura
de preparação para utilizar a Cache Local para permitir um ciclo de vida de teste de implementação de sem
emenda para a realização se obtém os benefícios da Cache Local para a ranhura de produção.
Teste o seu site contra a sua ranhura de encenação.
Quando estiver pronto, emita uma operação de troca entre as suas ranhuras de Preparação e Produção.
As configurações pegajosas incluem nome e pegajosa para uma ranhura. Assim, quando a ranhura de
Encenação é trocada em Produção, herda as definições da aplicação Cache Local. A ranhura de produção
recém-trocada irá contra a cache local após alguns minutos e será aquecida como parte do aquecimento da
ranhura após a troca. Assim, quando a troca de slot estiver completa, a sua ranhura de produção está a correr
contra a cache local.
Perguntas Mais Frequentes (FAQ)

Como posso saber se o Cache Local se aplica à minha aplicação?
Se a sua aplicação necessitar de uma loja de conteúdos de alto desempenho e fiável, não utiliza a loja de
conteúdos para escrever dados críticos no prazo de execução, e tem menos de 2 GB em tamanho total, então a
resposta é "sim"! Para obter o tamanho total das suas pastas/site e /extensões/site, pode utilizar a extensão do site
"Utilização do Disco de Web Apps Azure".
Como posso saber se o meu site mudou para usar o Cache Local?
Se estiver a utilizar a função Cache Local com Ambientes de Preparação, a operação de troca não termina até que
a Cache Local esteja aquecida. Para verificar se o seu site está a correr contra WEBSITE_LOCALCACHE_READY a Cache
Local, pode verificar a variável ambiente do processo do trabalhador . Utilize as instruções na página variável
ambiente do processo do trabalhador para aceder à variável ambiente do processo do trabalhador em várias
instâncias.
Acabei de publicar novas mudanças, mas a minha aplicação não parece tê -las. Porquê?
Se a sua aplicação utilizar cache local, então precisa reiniciar o seu site para obter as mais recentes alterações. Não
quer publicar alterações num site de produção? Consulte as opções de slot na secção de boas práticas anteriores.
Onde estão os meus registos?
Com a Cache Local, os seus registos e pastas de dados parecem um pouco diferentes. No entanto, a estrutura das
suas subpastas permanece a mesma, exceto que as subpastas estão aninhadas sob uma subpasta com o formato
"identificador VM único" + carimbo de tempo.
Tenho cache local ativado, mas a minha aplicação ainda é reiniciada. Porquê? Pensei que o Cache Local ajudasse
com o reinício frequente das aplicações.
A Cache local ajuda a evitar o reinício da aplicação relacionada com o armazenamento. No entanto, a sua
aplicação ainda poderá ser reiniciada durante as atualizações planeadas da infraestrutura do VM. A aplicação geral
reinicia que experimenta com a Cache Local ativada deve ser menor.
A Cache Local exclui que os diretórios sejam copiados para a unidade local mais rápida?
Como parte do passo que copia o conteúdo de armazenamento, qualquer pasta que seja chamada repositório é
excluída. Isto ajuda com cenários em que o conteúdo do seu site pode conter um repositório de controlo de fonte
que pode não ser necessário no funcionamento diário da app.
Visão geral do serviço de aplicações azure
Quando estiver a executar uma aplicação web, pretende estar preparado para quaisquer problemas que possam
surgir, desde 500 erros aos seus utilizadores, dizendo-lhe que o seu site está em baixo. O diagnóstico do Serviço
de Aplicações é uma experiência inteligente e interativa para ajudá-lo a resolver problemas com a sua aplicação
sem necessidade de configuração. Quando se depara com problemas com a sua aplicação, os diagnósticos do
Serviço de Aplicações apontam o que está errado em guiá-lo para a informação certa para mais facilmente e
rapidamente resolver o problema.
Embora esta experiência seja mais útil quando se está a ter problemas com a sua app nas últimas 24 horas, todos
os gráficos de diagnóstico estão sempre disponíveis para analisar.
Os diagnósticos do Serviço de Aplicações funcionam não só para a sua aplicação no Windows, mas também para
aplicações em Linux/contentores, App Service Environmente Azure Functions.
Diagnósticos de Serviço de Aplicações Abertas

Para aceder aos diagnósticos do Serviço de Aplicações, navegue para a sua aplicação web do App Service ou para
o App Service Environment no portal Azure. Na navegação à esquerda, clique em Diagnosticar e resolver
problemas .
Para funções Azure, navegue para a sua app de funções e na navegação de topo, clique nas funcionalidades da
Plataforma , e selecione Diagnosticar e resolver problemas a partir da secção de gestão de Recursos.
Na página inicial de diagnósticodo Serviço de Aplicações, pode escolher a categoria que melhor descreve o
problema com a sua aplicação utilizando as palavras-chave em cada azulejo da página inicial. Além disso, esta
página é onde pode encontrar Ferramentas de Diagnóstico para aplicações Windows. Consulte as ferramentas
de diagnóstico (apenas para aplicação Windows).
NOTE
Se a sua aplicação estiver em baixo ou a apresentar-se lentamente, pode recolher um rastreio de perfis para identificar a
causa principal do problema. O perfil é leve e é projetado para cenários de produção.
Interface interativa
Uma vez que selecione uma categoria de página inicial que melhor se alinha com o problema da sua aplicação, a
interface interativa dos diagnósticos do Serviço de Aplicações, Genie, pode guiá-lo através do diagnóstico e
resolução de problemas com a sua app. Pode utilizar os atalhos de azulejos fornecidos pela Genie para ver o
relatório completo de diagnóstico da categoria de problemas que está interessado. Os atalhos de azulejos
proporcionam-lhe uma forma direta de aceder às suas métricas de diagnóstico.
Depois de clicar nestes azulejos, pode ver uma lista de tópicos relacionados com o problema descrito no azulejo.
Estes tópicos fornecem fragmentos de informações notáveis a partir do relatório completo. Pode clicar em
qualquer um destes tópicos para investigar mais aprofundadamente as questões. Além disso, pode clicar no Ver
Relatório Completo para explorar todos os tópicos numa única página.
Relatório de diagnóstico
Depois de optar por investigar mais aprofundadamente o assunto clicando num tópico, pode ver mais detalhes
sobre o tema muitas vezes complementado com gráficos e marcações. O relatório de diagnóstico pode ser uma
ferramenta poderosa para identificar o problema com a sua aplicação.
Check-up de saúde
Se não sabe o que há de errado com a sua aplicação ou não sabe por onde começar a resolver problemas, o check-
up de saúde é um bom lugar para começar. O check-up de saúde analisa as suas aplicações para lhe dar uma visão
rápida e interativa que aponta o que é saudável e o que está errado, dizendo-lhe onde procurar investigar o
problema. A sua interface inteligente e interativa fornece-lhe orientação através do processo de resolução de
problemas. O check-up de saúde está integrado com a experiência Genie para aplicações windows e aplicação web
para baixo relatório de diagnóstico para aplicações Linux.
Gráficos de check-up de saúde
Há quatro gráficos diferentes no check-up de saúde.
pedidos e erros: Um gráfico que mostra o número de pedidos feitos nas últimas 24 horas juntamente com
erros do servidor HTTP.
desempenho da aplicação: Um gráfico que mostra o tempo de resposta nas últimas 24 horas para vários
grupos de percentil.
Utilização do CPU: Um gráfico que mostra o uso global de CPU por exemplo nas últimas 24 horas.
utilização da memória: Um gráfico que mostra o uso geral da memória física por exemplo nas últimas 24
horas.
Investigar problemas de código de aplicação (apenas para aplicação Windows)
Como muitos problemas de aplicações estão relacionados com problemas no seu código de aplicação, o
diagnóstico do App Service integra-se com os Insights de Aplicação para destacar exceções e problemas de
dependência para se relacionar com o tempo de inatividade selecionado. Os Insights de Aplicação têm de ser
ativados separadamente.
Para ver as exceções e dependências da Application Insights, selecione a aplicação web para baixo ou a
aplicação web aparatos lentos de azulejos.
Passos de resolução de problemas (apenas para aplicação Windows)
Se um problema for detetado com uma categoria de problema específico nas últimas 24 horas, pode ver o
relatório completo de diagnóstico, e os diagnósticos do Serviço de Aplicações podem levar-lhe a ver mais
conselhos de resolução de problemas e próximos passos para uma experiência mais guiada.
Ferramentas de diagnóstico (apenas para aplicação Windows)
DiagnósticoS As ferramentas incluem ferramentas de diagnóstico mais avançadas que o ajudam a investigar
problemas de código de aplicação, lentidão, cordas de ligação e muito mais. e ferramentas proativas que o ajudam
a mitigar problemas com o uso, pedidos e memória do CPU.
Monitorização proactiva do CPU
A monitorização proactiva do CPU proporciona-lhe uma forma fácil e proativa de tomar uma ação quando a sua
app ou processo infantil para a sua aplicação está a consumir elevados recursos cpu. Pode definir as suas próprias
regras de limiar de CPU para atenuar temporariamente um problema elevado de CPU até que a verdadeira causa
para o problema inesperado seja encontrada. Para mais informações, consulte atenuar os seus problemas de CPU
antes de acontecerem.
Auto -cura e cura automática proactiva

A cicatrização automática é uma ação de mitigação que pode tomar quando a sua aplicação está a ter um
comportamento inesperado. Pode definir as suas próprias regras com base na contagem de pedidos, pedido lento,
limite de memória e código de estado HTTP para desencadear ações de mitigação. Utilize a ferramenta para
atenuar temporariamente um comportamento inesperado até encontrar a causa da raiz. Para mais informações,
consulte Anunciando a nova experiência de cura automática em diagnósticos de serviçode aplicações.
Tal como a monitorização proactiva do CPU, a auto-cura proativa é uma solução chave-na-mão para atenuar
comportamentos inesperados da sua aplicação. A cura automática proactiva reinicia a sua aplicação quando o
Serviço de Aplicações determina que a sua aplicação se encontra num estado irrecuperável. Para mais
informações, consulte A introdução proactiva de auto-cura.
Navegador e alteração de análise (apenas para aplicação Windows)

Numa grande equipa com integração contínua e onde a sua app tem muitas dependências, pode ser difícil
identificar a mudança específica que causa um comportamento pouco saudável. A Navigator ajuda a obter
visibilidade na topologia da sua aplicação, tornando automaticamente um mapa de dependência da sua app e
todos os recursos na mesma subscrição. A Navigator permite-lhe visualizar uma lista consolidada de alterações
feitas pela sua app e as suas dependências e reduzir-se a uma mudança que causa comportamentos pouco
saudáveis. Pode ser acedido através do navegador de azulejos inicial e precisa de ser ativado antes de usá-lo pela
primeira vez. Para mais informações, consulte Obter visibilidade nas dependências da sua aplicação como
Navigator .
A análise de alterações de alterações de alterações de aplicações pode ser acedida através de atalhos de azulejos,
alterações de aplicações e falhas de aplicação na Disponibilidade e Desempenho para que possa utilizá-la
simultaneamente com outras métricas. Antes de utilizar a funcionalidade, tem de a ativar primeiro. Para mais
informações, consulte Anunciando a nova experiência de análise de alterações em Diagnósticosde Serviços de
Aplicações.
Publique as suas perguntas ou feedback no UserVoice adicionando "[Diag]" no título.
Configure uma app de serviço de aplicações no
portal Azure
Este tópico explica como configurar configurações comuns para aplicações web, back back back móvel ou
aplicação API usando o [portal Azure].
Configurar as definições da aplicação

No Serviço de Aplicações, as definições de aplicações são variáveis passadas como variáveis ambientais para o
código de aplicação. Para aplicações Linux e recipientes personalizados, o --env App Service passa as definições
da aplicação para o contentor usando a bandeira para definir a variável ambiental no recipiente.
No [portal Azure,]procure e selecione Ser viços de Aplicações e, em seguida, selecione a sua aplicação.
No menu esquerdo da aplicação, selecioneas definições de Configuração > da Aplicação .

Para ASP.NET e ASP.NET os desenvolvedores core, definir <appSettings> as definições de aplicativos no Serviço de
Aplicações é como defini-las em Web.config ou appsettings.json, mas os valores no Serviço de Aplicações
sobrepõem-se aos de Web.config ou appsettings.json. Pode manter as definições de desenvolvimento (por
exemplo, senha mySQL local) em Web.config ou appsettings.json, mas segredos de produção (por exemplo, senha
de base de dados Azure MySQL) seguros no Serviço de Aplicações. O mesmo código utiliza as definições de
desenvolvimento quando depura localmente, e utiliza os seus segredos de produção quando implantado no Azure.
Outras pilhas de idiomas, da mesma forma, obtêm as definições da aplicação como variáveis ambientais no tempo
de execução. Para passos específicos da pilha de idiomas, consulte:
ASP.NET Core
Node.js
PHP
Python
Java
Ruby
Personalizar contentores
As definições da aplicação são sempre encriptadas quando armazenadas (encriptadas em repouso).
NOTE
As definições da aplicação também podem ser resolvidas a partir do Cofre chave utilizando referências chave vault.
Mostrar valores ocultos

Por padrão, os valores para definições de aplicações estão escondidos no portal para segurança. Para ver um valor
oculto de uma definição de aplicação, clique no campo Valor dessa definição. Para ver os valores de todas as
definições da aplicação, clique no botão de valor do Show.
Adicionar ou editar
Para adicionar uma nova definição de aplicação, clique na definição de nova aplicação . No diálogo, pode colar
a regulação à ranhura atual.
Para editar uma definição, clique no botão Editar no lado direito.
Quando terminar, clique em Atualizar . Não se esqueça de clicar em Guardar de volta na página de
Configuração.
NOTE
Num recipiente Linux padrão ou num recipiente Linux personalizado, qualquer estrutura chave
ApplicationInsights:InstrumentationKey JSON aninhada ApplicationInsights__InstrumentationKey no nome de
definição da aplicação como deve ser configurada no App Service como para o nome chave. Por outras : palavras, __
qualquer um deve ser substituído por (duplo sublinhado).
Editar a granel
Para adicionar ou editar as definições de aplicações a granel, clique no botão de edição Avançada. Quando
terminar, clique em Atualizar . Não se esqueça de clicar em Guardar de volta na página de Configuração.
As definições da aplicação têm a seguinte formatação JSON:
[
{
"name": "<key-1>",
"value": "<value-1>",
"slotSetting": false
},
{
"name": "<key-2>",
"value": "<value-2>",
},
...
]
Configurar cadeias de ligação

No [portal Azure,]procure e selecione Ser viços de Aplicações e, em seguida, selecione a sua aplicação. No menu
esquerdo da aplicação, selecioneas definições de Configuração > da Aplicação .
Para ASP.NET e ASP.NET programadores Core, configurar as <connectionStrings> cordas de ligação no Serviço de
Aplicações é como defini-las em Web.config, mas os valores que definiu no Serviço de Aplicações sobrepõem-se
aos da Web.config. Pode manter as definições de desenvolvimento (por exemplo, um ficheiro de base de dados)
em Web.config e segredos de produção (por exemplo, credenciais de base de dados SQL) com segurança no
Serviço de Aplicações. O mesmo código utiliza as definições de desenvolvimento quando depura localmente, e
utiliza os seus segredos de produção quando implantado no Azure.
Para outras pilhas de idiomas, é melhor utilizar as definições da aplicação, porque as cordas de ligação requerem
formatação especial nas teclas variáveis para aceder aos valores. No entanto, aqui está uma exceção: certos tipos
de bases de dados do Azure são apoiados juntamente com a aplicação se configurar as suas cordas de ligação na
sua aplicação. Para mais informações, veja o que é apoiado. Se não precisar desta cópia de segurança
automatizada, utilize as definições da aplicação.
No tempo de execução, as cordas de ligação estão disponíveis como variáveis ambientais, pré-fixadas com os
seguintes tipos de ligação:
SQLServer: SQLCONNSTR_
Mysql: MYSQLCONNSTR_
SQLAzure: SQLAZURECONNSTR_
Personalizado: CUSTOMCONNSTR_
PostgreSQL: POSTGRESQLCONNSTR_
Por exemplo, uma cadeia de ligação MySql chamada string1 de ligação pode ser acedida como variável
MYSQLCONNSTR_connectionString1 ambiental . Para passos específicos da pilha de idiomas, consulte:
ASP.NET Core
Node.js
PHP
Python
Java
Ruby
Personalizar contentores
As cordas de ligação são sempre encriptadas quando armazenadas (encriptadas em repouso).
NOTE
As cordas de ligação também podem ser resolvidas a partir do Cofre chave utilizando referências chave vault.
Mostrar valores ocultos

Por padrão, os valores das cordas de ligação estão escondidos no portal para segurança. Para ver um valor oculto
de uma cadeia de ligação, basta clicar no campo Valor dessa corda. Para ver os valores de todas as cordas de
ligação, clique no botão de valor do Show.
Adicionar ou editar
Para adicionar uma nova cadeia de ligação, clique em Nova cadeia de ligação . No diálogo, pode colar a corda de
ligação à ranhura atual.
Para editar uma definição, clique no botão Editar no lado direito.
Quando terminar, clique em Atualizar . Não se esqueça de clicar em Guardar de volta na página de
Configuração.
Editar a granel
Para adicionar ou editar cordas de ligação a granel, clique no botão de edição Avançada. Quando terminar,
clique em Atualizar . Não se esqueça de clicar em Guardar de volta na página de Configuração.
As cordas de ligação têm a seguinte formatação JSON:
[
{
"name": "name-1",
"value": "conn-string-1",
"type": "SQLServer",
},
{
"name": "name-2",
"value": "conn-string-2",
"type": "PostgreSQL",
},
...
]
Configurar as definições gerais

esquerdo da aplicação, selecioneconfigurações gerais de configuração > .
Aqui, pode configurar algumas definições comuns para a aplicação. Algumas definições exigem que se dimensione
para níveis de preços mais elevados.
Configurações de stack : A pilha de software para executar a aplicação, incluindo o idioma e as versões SDK.
Para aplicações Linux e aplicações de contentores personalizadas, também pode definir um comando ou
ficheiro de arranque opcional.
Definições da plataforma : Permite configurar as definições para a plataforma de hospedagem, incluindo:
Bitness : 32-bit ou 64-bit.
Protocolo WebSocket : Para ASP.NET SignalR ou socket.io,por exemplo.
Always On : Mantenha a aplicação carregada mesmo quando não há trânsito. É necessário para
WebJobs contínuos ou para WebJobs que são desencadeados usando uma expressão CRON.
NOTE
Com a funcionalidade Always On, não se pode controlar o ponto final. Envia sempre um pedido para a raiz de
aplicação.
Versão gerida do gasoduto : O [modo de gasoduto]IIS . Desloque-o para Classic se tiver uma
aplicação antiga que requer uma versão mais antiga do IIS.
Versão HTTP : Definir para 2.0 para permitir o suporte ao protocolo HTTPS/2.
NOTE
A maioria dos navegadores modernos suportam o protocolo HTTP/2 apenas sobre tLS, enquanto o tráfego não
encriptado continua a usar HTTP/1.1. Para garantir que os navegadores de clientes se conectam à sua aplicação com
HTTP/2, guarde o seu nome DNS personalizado. Para mais informações, consulte Secure um nome DNS
personalizado com uma ligação TLS/SSL no Serviço de Aplicações Azure.
Afinidade ARR : Numa implantação em várias instâncias, certifique-se de que o cliente é encaminhado
para o mesmo caso durante a vida útil da sessão. Pode definir esta opção para Off para aplicações
apátridas.
Depuração : Ative a depuração remota para aplicações ASP.NET, ASP.NET Coreou Node.js. Esta opção desliga-se
automaticamente após 48 horas.
Cer tificados de cliente de entrada : exigir certificados de cliente em autenticação mútua.
Configurar documentos predefinidos

Esta definição é apenas para aplicações windows.
esquerdo da aplicação, selecionedocumentos Padrão de Configuração > .
O documento predefinido é a página web que é exibida no URL raiz para um site. O primeiro ficheiro
correspondente na lista é utilizado. Para adicionar um novo documento predefinido, clique em Novo documento .
Não se esqueça de clicar em Guardar .
Se a aplicação utilizar módulos que encaminham com base em URL em vez de servir conteúdo estático, não há
necessidade de documentos predefinidos.
Configurar mapeamentos de caminhos

esquerdo da aplicação, selecionemapeamentos de Caminho de Configuração > .
A página de mapeamento si mostra coisas diferentes com base no tipo S.

Aplicativos para janelas (não contentorizados)
Para aplicações Windows, pode personalizar os mapeamentos do manipulador IIS e aplicações virtuais e
diretórios.
Os mapeamentos do manipulador permitem adicionar processadores de script personalizados para lidar com
pedidos de extensões de ficheiros específicas. Para adicionar um manipulador personalizado, clique em Novo
manipulador . Configure o manipulador da seguinte forma:
Extensão . A extensão do ficheiro que pretende manusear, como * *.php* ou handler.fcgi.
Processador script . O caminho absoluto do processador de scripts para si. Os pedidos para ficheiros que
correspondam à extensão do ficheiro são processados pelo processador de scripts. Use o D:\home\site\wwwroot
caminho para se referir ao diretório raiz da sua aplicação.
Argumentos. Argumentos opcionais da linha de comando para o processador de scripts.
Cada aplicação tem o / caminho de D:\home\site\wwwroot raiz padrão ( ) mapeado para onde o seu código é
implementado por padrão. Se a sua raiz de aplicação estiver numa pasta diferente, ou se o seu repositório tiver
mais do que uma aplicação, pode editar ou adicionar aplicações virtuais e diretórios aqui. Clique em Nova
aplicação vir tual ou diretório.
Para configurar aplicações e diretórios virtuais, especifique cada diretório D:\home virtual e o seu caminho físico
correspondente em relação à raiz do website ( ). Opcionalmente, pode selecionar a caixa de verificação da
Aplicação para marcar um diretório virtual como aplicação.
Aplicativos contentorizados
Pode adicionar armazenamento personalizado para a sua aplicação contentorizada. As aplicações contentorizadas
incluem todas as aplicações Linux e também os recipientes personalizados Windows e Linux que estão em
execução no Serviço de Aplicações. Clique no Novo Monte de Armazenamento Azure e configure o seu
armazenamento personalizado da seguinte forma:
Nome : O nome do visor.
Opções de configuração : Básico ou Avançado .
Contas de armazenamento : A conta de armazenamento com o recipiente que deseja.
Tipo de armazenamento: Azure Blobs ou Azure Files .
NOTE
As aplicações de contentores windows suportam apenas ficheiros Azure.
Recipiente de armazenamento : Para configuração básica, o recipiente que desejar.

Nome da par tilha : Para configuração avançada, o nome da partilha de ficheiros.
Chave de acesso : Para uma configuração avançada, a chave de acesso.
Caminho do montagem : O caminho absoluto no seu recipiente para montar o armazenamento
personalizado.
Para obter mais informações, veja Fornecer conteúdo do Armazenamento do Microsoft Azure no Serviço de
Aplicações no Linux.
Configurar definições de pilha de idiomas

Para aplicativos Linux, consulte:
ASP.NET Core
Node.js
PHP
Python
Java
Ruby
Configurar recipientes personalizados

Consulte um recipiente linux personalizado para o Serviço de Aplicações Azure
Passos seguintes
Configure um nome de domínio personalizado no Serviço de Aplicações Azure
Configurar ambientes de teste no Serviço de Aplicações do Azure
Ativar registos de diagnóstico
Escala uma aplicação no Serviço de Aplicações Azure
Monitorização de bases no Serviço de Aplicações Azure
Alterar as definições host.config com applicationHost.xdt
Configure PHP no Azure App Service
Introdução
Este guia mostra-lhe como configurar o tempo de execução PHP incorporado para aplicações web e aplicações API
no Azure App Service,fornecer um tempo de execução PHP personalizado e ativar extensões. Para utilizar o Serviço
de Aplicações, inscreva-se para o [teste gratuito.] Para obter o máximo deste guia, você deve primeiro criar uma
aplicação PHP no Serviço de Aplicações.
Como: Alterar a versão PHP incorporada

Ao criar uma aplicação web, pode escolher a versão de PHP que será configurada. Consulte o PHP no Serviço de
Aplicações para obter informações atualizadas das versões atualmente suportadas.
Para verificar a versão de tempo de execução existente da sua aplicação, pode implementar um script que chame a
função [phpinfo().]
Para atualizar a versão PHP, siga um destes métodos:
Portal do Azure
1. Navegue pela sua aplicação no portal Azure e percorra a página de Configuração.
2. A partir da Configuração , selecione Definições Gerais e escolha a nova versão PHP.
3. Clique no botão Guardar na parte superior da lâmina de definições gerais.
CLI do Azure
Para utilizar a Interface Azure Command-Line, tem de instalar o Azure CLI no seu computador.
1. Abra o Terminal e faça login na sua conta.
az login
2. Verifique a lista de tempos de execução suportados.
az webapp list-runtimes | grep php
3. Desaprote a versão PHP para a aplicação.
az webapp config set --php-version {5.6 | 7.2 | 7.3} --name {app-name} --resource-group {resource-
group-name}
4. A versão PHP está agora definida. Pode confirmar estas definições:
az webapp show --name {app-name} --resource-group {resource-group-name}
Como: Alterar as configurações php incorporadas

Para qualquer tempo de execução PHP incorporado, pode alterar qualquer uma das opções de configuração
seguindo estes passos. (Para obter informações sobre as diretivas php.ini, consulte lista de diretivas php.ini.)
Alteração de PHP _ INI _ USER, PHP _ INI _ PERDIR, PHP _ INI _ TODAS as configurações
1. Adicione um ficheiro .user.ini ao seu diretório de raiz.
2. Adicione as definições de configuração ao .user.ini ficheiro utilizando a mesma sintaxe que utilizaria num
php.ini ficheiro. Por exemplo, se pretender ligar a display_errors definição e definir upload_max_filesize
a definição para 10M, o seu .user.ini ficheiro conteria este texto:
; Example Settings
display_errors=On
upload_max_filesize=10M
; OPTIONAL: Turn this on to write errors to d:\home\LogFiles\php_errors.log

; log_errors=On
3. Implemente a sua aplicação.

4. Reinicie a aplicação. (O reinício é necessário porque a frequência com que o PHP lê .user.ini os ficheiros é
regida pela user_ini.cache_ttl definição, que é uma definição de nível do sistema e é de 300 segundos (5
minutos) por defeito. Reiniciar a aplicação obriga o PHP a ler as novas definições no .user.ini ficheiro.)
Como alternativa à utilização de um .user.ini ficheiro, pode utilizar a função ini_set() em scripts para definir
opções de configuração que não são diretivas de nível do sistema.
Alterar as definições de configuração do SISTEMA PHP _ INI _
1. Adicione uma Configuração de Aplicativo à sua aplicação com a chave PHP_INI_SCAN_DIR e valor
d:\home\site\ini
2. Crie um settings.ini ficheiro utilizando a Kudu Console (http:// < nome do site > .scm.azurewebsite.net)
no d:\home\site\ini diretório.
3. Adicione as definições de configuração ao settings.ini ficheiro utilizando a mesma sintaxe que utilizaria
num php.ini ficheiro. Por exemplo, se pretender apontar curl.cainfo a definição para um *.crt ficheiro
e definir a definição 'wincache.maxfilesize' para 512 K, o seu settings.ini ficheiro conteria este texto:
; Example Settings
curl.cainfo="%ProgramFiles(x86)%\Git\bin\curl-ca-bundle.crt"
wincache.maxfilesize=512
4. Para recarregar as alterações, reinicie a sua aplicação.
Como: Permitir extensões no tempo de funcionação php predefinido

Como indicado na secção anterior, a melhor maneira de ver a versão PHP predefinida, a sua configuração padrão e
as extensões ativadas é implementar um script que chama phpinfo(). Para permitir extensões adicionais, seguindo
estes passos:
Configurar através das definições ini
1. Adicione um ext diretório ao d:\home\site diretório.
2. Coloque .dll os ficheiros de extensão no ext diretório (por exemplo, php_xdebug.dll ). Certifique-se de
que as extensões são compatíveis com a versão padrão de PHP e são compatíveis com VC9 e não-
resistentes a fios(nts).
3. Adicione uma Configuração de Aplicativo à sua aplicação com a chave PHP_INI_SCAN_DIR e valor
d:\home\site\ini
4. Crie um ini ficheiro d:\home\site\ini chamado extensions.ini .

5. Adicione as definições de configuração ao extensions.ini ficheiro utilizando a mesma sintaxe que utilizaria
num php.ini ficheiro. Por exemplo, se quisesse ativar as extensões MongoDB e XDebug, o seu
extensions.ini ficheiro conteria este texto:
; Enable Extensions
extension=d:\home\site\ext\php_mongo.dll
zend_extension=d:\home\site\ext\php_xdebug.dll
6. Reinicie a sua aplicação para carregar as alterações.

Configuração através da Definição de Aplicativos
1. Adicione um bin diretório ao diretório de raiz.
2. Coloque .dll os ficheiros de extensão no bin diretório (por exemplo, php_xdebug.dll ). Certifique-se de que
as extensões são compatíveis com a versão padrão de PHP e são compatíveis com VC9 e não-resistentes a
fios(nts).
4. Navegue pela sua aplicação no portal Azure e clique na secção Configuração localizada abaixo da secção
Definições.
5. A partir da lâmina de configuração, selecione Definições de aplicação .
6. Na secção definições de Aplicação, clique na definição de aplicação + nova e crie uma chave
PHP_EXTENSIONS. O valor desta chave seria um caminho relativo à raiz do site: bin\your-ext-file .
7. Clique no botão 'Actualização' na parte inferior e clique em Guardar acima do separador Definições de
Aplicação.
As extensões Zend também são suportadas usando uma chave PHP_ZENDEXTENSIONS. Para ativar várias
extensões, inclua uma lista de ficheiros separados por vírgula .dll para o valor de definição da aplicação.
Como: Use um tempo de execução PHP personalizado

Em vez do tempo de funcionação php predefinido, o Serviço de Aplicações pode utilizar um tempo de execução
PHP que fornece para executar scripts PHP. O tempo de execução que fornece pode ser configurado por um
php.ini ficheiro que também fornece. Para utilizar um tempo de funcionação PHP personalizado com o Serviço de
Aplicações, seguindo estes passos.
1. Obtenha uma versão compatível com VC9 ou VC11 não compatível com o Windows. As recentes versões de
PHP para Windows podem ser consultadas aqui: https://windows.php.net/download/ . Versões antigas podem
ser encontradas no arquivo aqui: https://windows.php.net/downloads/releases/archives/ .
2. Modifique o php.ini ficheiro para o seu tempo de funcionamento. Quaisquer definições de configuração que
sejam diretivas apenas para o sistema são ignoradas pelo Serviço de Aplicações. (Para obter informações sobre
diretivas apenas a nível do sistema, consulte [lista das diretivas php.ini]).
3. Opcionalmente, adicione extensões ao seu tempo de funcionamento PHP e ative-as no php.ini ficheiro.
4. Adicione um bin diretório ao seu diretório de raiz e coloque o diretório que contém o seu tempo de
funcionação PHP nele (por exemplo, bin\php ).
6. Navegue pela sua aplicação no portal Azure e clique na lâmina de configuração.
7. A partir da lâmina de configuração, selecione mapeamentos path .
8. Clique em + Novo Manipulador e adicione ao campo *.php extensão e adicione o caminho ao php-cgi.exe
executável no processador Script . Se colocar o seu tempo de funcionamento php bin no diretório na raiz da
sua aplicação, o caminho é D:\home\site\wwwroot\bin\php\php-cgi.exe .
9. Na parte inferior, clique em Update para terminar de adicionar o mapeamento do manipulador.
10. Clique em Guardar para guardar as alterações.
Como: Permitir a automação do compositor em Azure

Por padrão, o App Service não faz nada com o compositor.json, se tiver um no seu projeto PHP. Se utilizar a
implementação do Git,pode ativar o processamento do compositor.json durante git push a extensão do
Compositor.
NOTE
Você pode votar no suporte do compositor de primeira classe no Serviço de Aplicações aqui!
1. Na lâmina da sua aplicação PHP no portal Azure,clique em Tools > Extensões de Ferramentas .
2. Clique em Adicionar e, em seguida, clique em Compositor .

3. Clique em OK para aceitar termos legais. Clique em OK novamente para adicionar a extensão.
A lâmina de extensões instalada mostra a extensão do Compositor.
4. Agora, numa janela terminal da sua máquina local, git add execute, git commit e para a git push sua
aplicação. Note que o Compositor está a instalar dependências definidas em composer.json.
Próximos passos
Para mais informações, consulte o Centro de Desenvolvimento PHP.
Configure um aplicativo Windows Java para o
Serviço de Aplicações Azure
O Azure App Service permite que os desenvolvedores de Java construam, implementem e dimensionem
rapidamente as suas aplicações Web Tomcat num serviço totalmente gerido com base no Windows. Implemente
aplicações com plugins Maven da linha de comando ou em editores como IntelliJ, Eclipse ou Visual Studio Code.
Este guia fornece conceitos e instruções fundamentais para os desenvolvedores java que utilizam no Serviço de
Aplicações. Se nunca usou o Azure App Service, deve ler primeiro o Java quickstart. Perguntas gerais sobre a
utilização do Serviço de Aplicações que não são específicas para o desenvolvimento de Java são respondidas no
Serviço de Aplicações Windows FAQ.
Implementação da sua aplicação

Pode utilizar o Plugin da Aplicação Web Azure para a Maven implementar os seus ficheiros .war. A implantação com
IDEs populares também é suportada com O Kit de Ferramentas Azure para IntelliJ ou Azure Toolkit para Eclipse.
Caso contrário, o seu método de implantação dependerá do seu tipo de arquivo:
Para implementar ficheiros de guerra para /api/wardeploy/ o Tomcat, utilize o ponto final para publicar o
ficheiro de arquivo. Para mais informações sobre esta API, consulte esta documentação.
Para implementar ficheiros .jar para /api/zipdeploy/ Java SE, utilize o ponto final do site Kudu. Para mais
informações sobre esta API, consulte esta documentação.
Não implante a sua .guerra usando FTP. A ferramenta FTP foi concebida para carregar scripts de arranque,
dependências ou outros ficheiros de tempo de execução. Não é a escolha ideal para implementar aplicações web.
Aplicativos de registo e depuração

Relatórios de desempenho, visualizações de tráfego e check-ups de saúde estão disponíveis para cada aplicação
através do portal Azure. Para mais informações, consulte a visão geral dos diagnósticos do Serviço de Aplicações
Azure.
Utilizar gravador de voo
Todos os tempos de execução java no Serviço de Aplicações usando os JVMs Azul vêm com o Gravador de Voo
Zulu. Você pode usá-lo para gravar eventos de nível JVM, sistema e Java para monitorizar o comportamento e
problemas de resolução de problemas nas suas aplicações Java.
Para obter uma gravação cronometrada, necessitará do PID (PROCESS ID) da aplicação Java. Para encontrar o PID,
abra um navegador para o site SCM da sua aplicação web em https://.scm.azurewebsites.net/ProcessExplorer/. Esta
página mostra os processos de execução na sua aplicação web. Encontre o processo denominado "java" na tabela e
copie o PID correspondente (ID do processo).
Em seguida, abra a Consola Debug na barra de ferramentas superior do site SCM e execute o seguinte comando.
Substitua <pid> com o ID de processo que copiou anteriormente. Este comando iniciará uma gravação de 30
segundos do timed_recording_example.jfr seu D:\home pedido java e gerará um ficheiro nomeado no diretório.
jcmd <pid> JFR.start name=TimedRecording settings=profile duration=30s

filename="D:\home\timed_recording_example.JFR"
Para mais informações, por favor leia as informações sobre o comando da JCMD.
Analisar .jfr ficheiros
Utilize FTPS para transferir o seu ficheiro JFR para a sua máquina local. Para analisar o ficheiro JFR, descarregue e
instale o Controlo da Missão Zulu. Para obter instruções sobre o Controlo da Missão Zulu, consulte a
documentação Azul e as instruções de instalação.
Pode aceder aos registos de consolas gerados a partir do interior do recipiente. Primeiro, ligue a exploração do
contentor executando o seguinte comando na Cloud Shell:
az webapp log config --name <app-name> --resource-group myResourceGroup --docker-container-logging filesystem
Quando o registo do contentor estiver ligado, faça o seguinte comando para ver o fluxo de registo:
az webapp log tail --name <app-name> --resource-group myResourceGroup
Se não vir os registos da consola imediatamente, volte a consultar dentro de 30 segundos.
NOTE
Também pode inspecionar os ficheiros https://<app-name>.scm.azurewebsites.net/api/logs/docker de registo do
navegador em .
Para parar o streaming de Ctrl + C registo a qualquer momento, escreva .

Para mais informações, consulte os registos do Stream na Cloud Shell.
Registo de aplicações
Ative o registo de aplicações através do portal Azure ou do Azure CLI para configurar o App Service para escrever a
saída padrão da consola da sua aplicação e os fluxos de erros padrão da consola para o sistema de ficheiros local
ou para o Armazenamento De Blob Azure. O registo na instância do sistema de ficheiros do Serviço de Aplicações
local é desativado 12 horas após a sua configuração. Se necessitar de retenção mais longa, configure a aplicação
para escrever saída para um recipiente de armazenamento Blob. Os registos das suas aplicações Java e Tomcat
podem ser encontrados no /LogFiles/Application/diretório.
Se a sua aplicação utilizar logback ou Log4j para rastreio, pode reencaminhar estes vestígios para revisão em
Insights de Aplicação Azure utilizando as instruções de configuração de configuração de configuração de login em
Explore Java tracelogs in Application Insights.
Personalização e afinação
O Azure App Service suporta a afinação e personalização da caixa através do portal Azure e clI. Reveja os seguintes
artigos para a configuração de aplicações web não específicas de Java:
Configurar um domínio personalizado
Configure ligações TLS
Adicione um CDN
Configure o site kudu
Definir opções de tempo de execução de Java
Para definir a memória atribuída ou outras opções de JAVA_OPTS prazo de execução JVM, crie uma definição de
aplicação nomeada com as opções. O Serviço de Aplicações passa esta definição como uma variável ambiental
para o tempo de funcionação de Java quando começa.
No portal Azure, no âmbito das Definições de Aplicação para a aplicação web, criar uma nova definição de
aplicação chamada JAVA_OPTS que inclua as configurações adicionais, tais como -Xms512m -Xmx1204m .
Para configurar a definição da aplicação a partir do plugin Maven, adicione etiquetas de definição/valor na secção
plugin Azure. O exemplo que se segue define um tamanho mínimo e máximo de monte java específico:
<appSettings>
<property>
<name>JAVA_OPTS</name>
<value>-Xms512m -Xmx1204m</value>
</property>
</appSettings>
Os desenvolvedores que executam uma única aplicação com uma ranhura de implementação no seu plano de
Serviço de Aplicações podem usar as seguintes opções:
Instâncias B1 e S1: -Xms1024m -Xmx1024m
Casos B2 e S2: -Xms3072m -Xmx3072m
Casos B3 e S3: -Xms6144m -Xmx6144m
Ao afinar as definições de pilhas de aplicações, reveja os detalhes do plano do App Service e tenha em conta várias
aplicações e o slot de implementação precisa para encontrar a melhor alocação de memória.
Ligue as tomadas web
Ligue o suporte para tomadas web no portal Azure nas definições de Aplicação para a aplicação. Terá de reiniciar
a aplicação para que a definição faça efeito.
Ligue o suporte da tomada web utilizando o Azure CLI com o seguinte comando:
az webapp config set --name <app-name> --resource-group <resource-group-name> --web-sockets-enabled true
Em seguida, reinicie a sua aplicação:
az webapp stop --name <app-name> --resource-group <resource-group-name>

az webapp start --name <app-name> --resource-group <resource-group-name>
Definir codificação de caracteres padrão

No portal Azure, no âmbito das Definições de Aplicação para a aplicação web, criar uma nova configuração de
aplicação com JAVA_OPTS valor. -Dfile.encoding=UTF-8
Em alternativa, pode configurar a definição da aplicação utilizando o plugin Maven do Serviço de Aplicações.
Adicione o nome de definição e as etiquetas de valor na configuração do plugin:
<appSettings>
<property>
<name>JAVA_OPTS</name>
<value>-Dfile.encoding=UTF-8</value>
</property>
</appSettings>
Pré -compilação de ficheiros JSP

Para melhorar o desempenho das aplicações Tomcat, pode compilar os seus ficheiros JSP antes de ser
implementado no App Service. Pode utilizar o plugin Maven fornecido pela Apache Sling, ou utilizar este ficheiro de
construção Ant.
Aplicações seguras
As aplicações Java em execução no App Service têm o mesmo conjunto de boas práticas de segurança que outras
aplicações.
Utilizadores autenticados (Easy Auth)
Configurar a autenticação da aplicação no portal Azure com a opção Autenticação e Autorização. A partir daí,
pode ativar a autenticação utilizando o Diretório Ativo do Azure ou logins sociais como facebook, Google ou
GitHub. A configuração do portal Azure só funciona quando configurar um único fornecedor de autenticação. Para
mais informações, consulte a configuração da sua app App Service para utilizar o login do Azure Ative Directory e
os artigos relacionados para outros fornecedores de identidade. Se precisar de ativar vários fornecedores de
sessão, siga as instruções no artigo de autenticação do Serviço de Aplicações personalizado.
Tomcat
A sua aplicação Tomcat pode aceder às reclamações do utilizador diretamente a partir do servlet, lançando o objeto
principal para um objeto Map. O objeto do Mapa irá mapear cada tipo de reclamação para uma coleção das
reivindicações desse tipo. No código abaixo, request é HttpServletRequest um exemplo de .
Map<String, Collection<String>> map = (Map<String, Collection<String>>) request.getUserPrincipal();
Agora pode inspecionar Map o objeto para qualquer reclamação específica. Por exemplo, o código seguinte itera
através de todos os tipos de reclamação e imprime o conteúdo de cada coleção.
for (Object key : map.keySet()) {

Object value = map.get(key);
if (value != null && value instanceof Collection {
Collection claims = (Collection) value;
for (Object claim : claims) {
System.out.println(claims);
}
}
}
Para assinar os utilizadores, use o /.auth/ext/logout caminho. Para realizar outras ações, consulte a documentação
sobre autenticação e utilizaçãode autorização de serviço de aplicação. Existe também documentação oficial sobre a
interface Tomcat HttpServletRequest e os seus métodos. Os seguintes métodos de servlet também são hidratados
com base na configuração do seu Serviço de Aplicações:
public boolean isSecure()

public String getRemoteAddr()
public String getRemoteHost()
public String getScheme()
public int getServerPort()
Para desativar esta funcionalidade, WEBSITE_AUTH_SKIP_PRINCIPAL crie 1 uma Definição de Aplicação com um valor
de . Para desativar todos os filtros de servlet adicionados pelo App Service, crie uma definição com
WEBSITE_SKIP_FILTERS um valor de 1 .
Configurar TLS/SSL
Siga as instruções no nome 'Secure' um DNS personalizado com uma ligação TLS no Serviço de Aplicações Azure
para fazer o upload de um certificado TLS/SSL existente e ligá-lo ao nome de domínio da sua aplicação. Por defeito,
a sua aplicação continuará a permitir que as ligações HTTP sigam os passos específicos do tutorial para impor sSL e
TLS.
Utilizar referências keyVault
O Azure KeyVault fornece uma gestão secreta centralizada com políticas de acesso e histórico de auditoria. Pode
armazenar segredos (como palavras-passe ou cordas de ligação) no KeyVault e aceder a estes segredos na sua
aplicação através de variáveis ambientais.
Em primeiro lugar, siga as instruções para conceder o acesso da sua aplicação ao Key Vault e fazer uma referência
ao KeyVault ao seu segredo numa Definiçãode Aplicação . Pode validar que a referência resolve o segredo
imprimindo a variável ambiental ao aceder remotamente ao terminal do Serviço de Aplicações.
Para injetar estes segredos no seu ficheiro de configuração Spring ${MY_ENV_VAR} ou Tomcat, utilize sintaxe de
injeção variável ambiente (). Para os ficheiros de configuração da Mola, consulte esta documentação sobre
configurações externas.
Configure plataformas APM

Esta secção mostra como ligar as aplicações java implantadas no Serviço de Aplicações Azure em Linux com as
plataformas de monitorização de desempenho da aplicação NewRelic e AppDynamics (APM).
Configurar nova relíquia
1. Criar uma conta New Relic no NewRelic.com
2. Descarregue o agente Java da NewRelic, terá um nome de ficheiro semelhante ao newrelic-java-x.x.x.x.zip.
3. Copie a chave da sua licença, terá de a configurar para configurar o agente mais tarde.
4. Utilize a consola Kudu para criar um novo diretório /home/site/wwwroot/apm.
5. Faça upload dos ficheiros do agente New Relic Java desembalados num diretório em /home/site/wwwroot/apm.
Os ficheiros do seu agente devem estar em /home/site/wwwroot/apm/newrelic.
6. Modifique o ficheiro YAML em /home/site/wwwroot/apm/newrelic/newrelic.yml e substitua o valor da licença
de proprietário por conta própria.
7. No portal Azure, navegue para a sua aplicação no Serviço de Aplicações e crie uma nova Definição de
Aplicações.
Se a sua aplicação estiver a JAVA_OPTS utilizar o
-javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar Java SE, crie uma variável ambiental com o
valor.
Se estiver a usar o Tomcat, crie uma variável ambiental com CATALINA_OPTS o valor.
-javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar
Configure AppDynamics
1. Criar uma conta AppDynamics em AppDynamics.com
2. Descarregue o agente Java a partir do website appDynamics, o nome do ficheiro será semelhante ao
AppServerAgent-x.x.x.xxxxx.zip
3. Utilize a consola Kudu para criar um novo diretório /home/site/wwwroot/apm.
4. Faça upload dos ficheiros do agente Java para um diretório em /home/site/wwwroot/apm. Os ficheiros do seu
agente devem estar em /home/site/wwwroot/apm/appdynamics.
5. No portal Azure, navegue para a sua aplicação no Serviço de Aplicações e crie uma nova Definição de
Aplicações.
Se estiver a usar java SE, JAVA_OPTS crie
-javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-
name>
uma <app-name> variável ambiental com o valor onde está o seu nome de Serviço de Aplicações.
Se estiver a usar o Tomcat, crie
-javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-
name>
<app-name> uma variável ambiental com CATALINA_OPTS o valor onde está o nome do Serviço de
Aplicações.
Se já tiver uma JAVA_OPTS variável ambiental para ou CATALINA_OPTS , anexar a opção -javaagent:/... até ao
fim do valor atual.
Origens de dados
Tomcat
Estas instruções aplicam-se a todas as ligações de base de dados. Terá de preencher os espaços reservados com o
nome da classe de motorista da sua base de dados escolhida e o ficheiro JAR. Fornecido é uma tabela com nomes
de classe e transferências de motorista para bases de dados comuns.
B A SE DE DA DO S N O M E DA C L A SSE DO C O N DUTO R C O N DUTO R JDB C
PostgreSQL org.postgresql.Driver Transferir
MySQL com.mysql.jdbc.Driver Baixar (Selecione "Platform

Independent")
SQL Server Transferir

com.microsoft.sqlserver.jdbc.SQLServerDriver
Para configurar o Tomcat para utilizar a Conectividade da Base de Dados Java (JDBC) ou a Java Persistence API
(JPA), primeiro personalize a CATALINA_OPTS variável ambiental que é lida pela Tomcat no arranque. Defina estes
valores através de uma definição de aplicação no plugin Maven Service:
<appSettings>
<property>
<name>CATALINA_OPTS</name>
<value>"$CATALINA_OPTS -Ddbuser=${DBUSER} -Ddbpassword=${DBPASSWORD} -DconnURL=${CONNURL}"</value>
</property>
</appSettings>
Ou definir as variáveis ambientais na página definições > deconfiguração no portal Azure.

Em seguida, determine se a fonte de dados deve estar disponível para uma aplicação ou para todas as aplicações
em execução no servlet Tomcat.
Fontes de dados ao nível da aplicação
1. Crie um ficheiro context.xml no meta-INF/diretório do seu projeto. Crie o meta-INF/diretório se não existir.
2. No contexto.xml, Contextadicione um elemento para ligar a fonte de dados a um endereço JNDI. Substitua
driverClassName o espaço reservado pelo nome da classe do condutor na tabela acima.
<Context>
<Resource
name="jdbc/dbconnection"
type="javax.sql.DataSource"
url="${dbuser}"
driverClassName="<insert your driver class name>"
username="${dbpassword}"
password="${connURL}"
/>
</Context>
3. Atualize o web.xml da sua aplicação para utilizar a fonte de dados na sua aplicação.
<resource-env-ref>
<resource-env-ref-name>jdbc/dbconnection</resource-env-ref-name>
<resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
</resource-env-ref>
Finalizar a configuração
Finalmente, colocaremos os JARs do condutor na classe Tomcat e reiniciaremos o seu Serviço de Aplicações.
Certifique-se de que os ficheiros do condutor JDBC estão disponíveis para o classloader Tomcat colocando-os no
diretório /casa/tomcat/lib. (Crie este diretório se já não existir.) Para fazer o upload destes ficheiros para a sua
instância do Serviço de Aplicações, execute os seguintes passos:
1. Na Cloud Shell,instale a extensão webapp:
az extension add -–name webapp
2. Executar o seguinte comando CLI para criar um túnel SSH do seu sistema local para o Serviço de Aplicações:
az webapp remote-connection create --resource-group <resource-group-name> --name <app-name> --port

<port-on-local-machine>
3. Ligue-se à porta de túneis local com o seu cliente SFTP e faça o upload dos ficheiros para a pasta
/home/tomcat/lib.
Em alternativa, pode utilizar um cliente FTP para carregar o condutor da JDBC. Siga estas instruções para obter as
suas credenciais FTP.
Configurar tomcat
Para editar os ficheiros de configuração da server.xml Tomcat ou de outros ficheiros de configuração, tome
primeiro uma nota da sua versão principal tomcat no portal.
1. Encontre o diretório da casa tomcat env para a sua versão executando o comando. Procure a variável
ambiental AZURE_TOMCAT que começa e corresponda à sua versão principal. Por exemplo, AZURE_TOMCAT85_HOME
aponta para o diretório Tomcat para tomcat 8.5.
2. Depois de ter identificado o diretório caseiro tomcat para a D:\home sua versão, copie o diretório de
configuração para . Por exemplo, AZURE_TOMCAT85_HOME se tivesse D:\Program Files (x86)\apache-tomcat-8.5.37
um valor de , o novo D:\home\apache-tomcat-8.5.37 caminho do diretório copiado seria .
Finalmente, reinicie o seu Serviço de Aplicações. Os seus destacamentos D:\home\site\wwwroot\webapps devem ir

como antes.
Configure Java SE
Ao executar um . A aplicação JAR no server.port Java SE no Windows, é aprovada como uma opção de linha de
comando à medida que a sua aplicação começa. Pode resolver manualmente a porta HTTP HTTP_PLATFORM_PORT a
partir da variável ambiental, . O valor desta variável ambiental será a porta HTTP que a sua aplicação deve ouvir.
Declaração de apoio em tempo de execução de Java

Versões jdk e manutenção
O Kit de Desenvolvimento Java (JDK) suportado pela Azure é zulu fornecido através da Azul Systems.
As principais atualizações de versão serão fornecidas através de novas opções de tempo de execução no Serviço de
Aplicações Azure para Windows. Os clientes atualizam estas versões mais recentes da Java configurando a sua
implementação do Serviço de Aplicações e são responsáveis por testar e garantir que a grande atualização satisfaz
as suas necessidades.
Os JDKs suportados são automaticamente corrigidos trimestralmente em janeiro, abril, julho e outubro de cada
ano. Para mais informações sobre Java no Azure, consulte este documento de suporte.
Atualizações de segurança
Patches e correções para grandes vulnerabilidades de segurança serão lançados assim que ficarem disponíveis na
Azul Systems. Uma vulnerabilidade "importante" é definida por uma pontuação base de 9.0 ou superior no Sistema
de Pontuação de Vulnerabilidade Comum NIST, versão 2.
A Tomcat 8.0 chegou ao Fim da Vida (EOL) a 30 de setembro de 2018. Embora o tempo de execução ainda seja
aviável no Serviço de Aplicações Azure, o Azure não aplicará atualizações de segurança ao Tomcat 8.0. Se possível,
emigre as suas candidaturas para Tomcat 8.5 ou 9.0. Tanto o Tomcat 8.5 como o 9.0 estão disponíveis no Serviço de
Aplicações Azure. Consulte o site oficial da Tomcat para mais informações.
Depreciação e reforma
Se um tempo de execução apoiado em Java for retirado, os desenvolvedores da Azure que utilizem o tempo de
execução afetado receberão um aviso de depreciação pelo menos seis meses antes do tempo de execução ser
retirado.
Desenvolvimento local
Os desenvolvedores podem baixar a Edição de Produção da Blue Zulu Enterprise JDK para desenvolvimento local a
partir do site de descarregamento da Azul.
Apoio ao desenvolvimento
O suporte ao produto para o Azul Zulu JDK suportado pelo Azure está disponível através da Microsoft no
desenvolvimento para Azure ou Azure Stack com um plano de suporte azure qualificado.
Suporte de tempo de execução
Os desenvolvedores podem abrir um problema com os JDKs Azul Zulu através do Suporte Azure se tiverem um
plano de suporte qualificado.
Passos seguintes
Este tópico fornece a declaração de suporte java Runtime para o Serviço de Aplicações Azure no Windows.
Para saber mais sobre hospedagem de aplicações web com o Azure App Service consulte a visão geral do
Para obter informações sobre Java sobre o desenvolvimento do Azure consulte Azure para Java Dev Center.
Integre a sua app com uma rede virtual Azure
Este artigo descreve a funcionalidade de Integração VNet do Serviço de Aplicações Azure e como conehá-la com
aplicações no Azure App Service. Com a Rede Virtual Azure (VNets), pode colocar muitos dos seus recursos
Azure numa rede não-internet-routable. A funcionalidade de Integração VNet permite que as suas aplicações
acedam a recursos dentro ou através de um VNet. A Integração VNet não permite que as suas aplicações sejam
acedidas em privado.
O Azure App Service tem duas variações na funcionalidade de Integração VNet:
Os sistemas multiarrendatários que suportam toda a gama de planos de preços exceto isolados.
O App Service Environment, que se implanta no seu VNet e suporta aplicações de planos de preços isolados.
A funcionalidade de Integração VNet é utilizada em aplicações multiarrendatárias. Se a sua aplicação estiver no
App Service Environment, então já está num VNet e não requer a utilização da funcionalidade de Integração
VNet para chegar a recursos no mesmo VNet. Para obter mais informações sobre todas as funcionalidades de
networking, consulte as funcionalidades de rede do Serviço de Aplicações.
A VNet Integration dá à sua aplicação acesso aos recursos no seu VNet, mas não concede acesso privado à sua
aplicação a partir do VNet. O acesso ao site privado refere-se a tornar uma aplicação acessível apenas a partir de
uma rede privada, como por exemplo dentro de uma rede virtual Azure. A VNet Integration é usada apenas para
fazer chamadas de saída da sua aplicação para o seu VNet. A funcionalidade de Integração VNet comporta-se de
forma diferente quando é usada com VNet na mesma região e com VNet noutras regiões. A funcionalidade de
Integração VNet tem duas variações:
Integração VNet Regional : Quando se conecta a redes virtuais do Azure Resource Manager na mesma
região, deve ter uma subnet dedicada no VNet com o qual está a integrar.
Integração VNet exigida por Gateway : Quando se conecta à VNet noutras regiões ou a uma rede virtual
clássica na mesma região, precisa de um gateway de rede virtual Azure aprovisionado no Alvo VNet.
As funcionalidades de Integração VNet:
Exija um plano de preços Standard, Premium, PremiumV2 ou Elástico Premium.
Suporte TCP e UDP.
Trabalhe com aplicações do Azure App Service e aplicações de função.
Há algumas coisas que a VNet Integração não suporta, como:
Montando uma unidade.
Integração de Diretório ativo.
NetBIOS.
A VNet Integration exigida por gateway fornece acesso a recursos apenas no VNet alvo ou em redes ligadas ao
alvo VNet com peering ou VPNs. A VNet Integration exigida por Gateway não permite o acesso aos recursos
disponíveis em ligações Azure ExpressRoute ou trabalha com pontos finais de serviço.
Independentemente da versão utilizada, a VNet Integration dá à sua aplicação acesso aos recursos no seu VNet,
mas não concede acesso privado à sua aplicação a partir do VNet. O acesso ao site privado refere-se a tornar a
sua aplicação acessível apenas a partir de uma rede privada, como por exemplo dentro de um Azure VNet. A
VNet Integration é apenas para fazer chamadas de saída da sua aplicação para o seu VNet.
Ativar a integração do VNet
1. Aceda ao UI de Rede no portal do Serviço de Aplicações. Em Integração VNet, selecione Clique aqui
para configurar .
2. Selecione Adicionar VNet .
3. A lista de drop-down contém todas as redes virtuais do Azure Resource Manager na sua subscrição na
mesma região. Por baixo disso está uma lista das redes virtuais do Gestor de Recursos em todas as outras
regiões. Selecione o VNet com o quais pretende integrar-se.
Se o VNet estiver na mesma região, ou crie uma nova sub-rede ou selecione uma sub-rede pré-
existente vazia.
Para selecionar um VNet noutra região, tem de ter um gateway VNet atado com o ponto para o site
ativado.
Para se integrar com um VNet clássico, em vez de selecionar a lista de drop-down da Rede Vir tual,
selecione Clique aqui para ligar a um VNet clássico . Selecione a rede virtual clássica que deseja.
O VNet alvo já deve ter um gateway de rede virtual a provisionado com o ponto a local ativado.
Durante a integração, a sua aplicação é reiniciada. Quando a integração estiver terminada, verá detalhes sobre o
VNet com o qual está integrado.

A utilização da Integração VNet regional permite que a sua aplicação aceda:
Recursos num VNet na mesma região que a sua aplicação.
Os recursos em VNets espreguiçadados para o VNet a sua aplicação está integrada.
Serviços seguros de serviço.
Recursos através das ligações Azure ExpressRoute.
Recursos no VNet com os qual está integrado.
Recursos através de ligações espreitadas, que incluem ligações Azure ExpressRoute.
Quando utilizar a Integração VNet com VNets na mesma região, pode utilizar as seguintes funcionalidades de
networking Azure:
Grupos de segurança de rede (NSGs) : Pode bloquear o tráfego de saída com um NSG colocado na sua
sub-rede de integração. As regras de entrada não se aplicam porque não pode usar a Integração VNet para
fornecer acesso à sua aplicação.
Tabelas de rotas (UDRs) : Pode colocar uma tabela de rota na sub-rede de integração para enviar o tráfego
de saída onde quiser.
Por padrão, a sua aplicação apenas encaminha o tráfego RFC1918 para o seu VNet. Se quiser encaminhar todo o
tráfego de saída para o seu VNet, aplique a definição da aplicação WEBSITE_VNET_ROUTE_ALL para a sua
aplicação. Para configurar a definição da aplicação:
1. Aceda ao UI de configuração no portal da aplicação. Selecione nova definição de aplicação .
2. Introduza WEBSITE_VNET_ROUTE_ALL na caixa Nome e introduza 1 na caixa Valor.
3. Selecione OK .
Se encaminhar todo o tráfego de saída para o seu VNet, está sujeito aos NSGs e UDRs que são aplicados na sua
sub-rede de integração. Quando encaminha todo o tráfego de saída para o seu VNet, os seus endereços de saída
ainda são os endereços de saída que estão listados nas propriedades da sua aplicação, a menos que forneça
rotas para enviar o tráfego para outro lugar.
Existem algumas limitações com a utilização da Integração VNet com VNets na mesma região:
Não se pode alcançar recursos através de ligações globais de observação.
A funcionalidade está disponível apenas a partir de novas unidades de escala do Azure App Service que
suportam planos do Serviço de Aplicações PremiumV2.
A sub-rede de integração pode ser utilizada apenas por um plano de Serviço de Aplicações.
A funcionalidade não pode ser utilizada por aplicações de plano isolado que se encontrem num Ambiente de
A funcionalidade requer uma sub-rede não utilizada que seja uma /27 com 32 endereços ou maior num VNet
do Gestor de Recursos Azure.
A aplicação e o VNet devem estar na mesma região.
Não é possível eliminar um VNet com uma aplicação integrada. Remova a integração antes de eliminar o
VNet.
Só é possível integrar-se com VNets na mesma subscrição que a aplicação.
Você pode ter apenas uma integração regional VNet por plano de Serviço de Aplicação. Várias aplicações no
mesmo plano de Serviço de Aplicações podem usar o mesmo VNet.
Não é possível alterar a subscrição de uma app ou de um plano enquanto há uma aplicação que está a usar a
Integração VNet regional.
A sua aplicação não consegue resolver endereços em Zonas Privadas Azure DNS sem alterações de
configuração
Um endereço é usado para cada instância de plano. Se escalar a sua aplicação em cinco instâncias, então são
utilizados cinco endereços. Uma vez que o tamanho da sub-rede não pode ser alterado após a atribuição, você
deve usar uma sub-rede que é grande o suficiente para acomodar qualquer escala que a sua app possa alcançar.
Um /26 com 64 endereços é o tamanho recomendado. A /26 com 64 endereços acomoda um plano Premium
com 30 instâncias. Quando escala um plano para cima ou para baixo, você precisa do dobro de endereços por
um curto período de tempo.
Se quiser que as suas apps num outro plano cheguem a um VNet que já esteja ligado a apps noutro plano,
selecione uma sub-rede diferente da que está a ser usada pela integração VNet pré-existente.
A funcionalidade é totalmente suportada tanto para aplicações web Windows como Linux. Todos os
comportamentos agem da mesma forma entre aplicações Windows e aplicações Linux.
A Integração Regional de VNet permite-lhe utilizar pontos finais de serviço. Para utilizar pontos finais de serviço
com a sua aplicação, utilize a Integração Regional de VNet para ligar a um VNet selecionado e, em seguida,
configure os pontos finais do serviço com o serviço de destino na sub-rede que utilizou para a integração. Se
então quisesse aceder a um serviço sobre os pontos finais de serviço:
1. Configure a Integração Regional de VNet com a sua aplicação web
2. ir para o serviço de destino e configurar pontos finais de serviço contra a sub-rede utilizada para a integração
Grupos de segurança de rede
Pode utilizar grupos de segurança de rede para bloquear o tráfego de entrada e saída de recursos num VNet.
Uma aplicação que utiliza a Integração VNet regional pode usar um grupo de segurança de rede para bloquear o
tráfego de saída para recursos no seu VNet ou na internet. Para bloquear o tráfego para endereços públicos, tem
de ter a definição de aplicação WEBSITE_VNET_ROUTE_ALL definida para 1. As regras de entrada num NSG não
se aplicam à sua aplicação porque a Integração VNet afeta apenas o tráfego de saída da sua aplicação.
Para controlar o tráfego de entrada na sua aplicação, utilize a funcionalidade Restrições de Acesso. Um NSG
aplicado à sua sub-rede de integração está em vigor, independentemente de quaisquer rotas aplicadas à sua
sub-rede de integração. Se WEBSITE_VNET_ROUTE_ALL estiver definido para 1 e não tiver rotas que afetem o
tráfego de endereço público na sua sub-rede de integração, todo o tráfego de saída ainda está sujeito a NSGs
atribuídos à sua sub-rede de integração. Se WEBSITE_VNET_ROUTE_ALL não estiver definido, os NSGs são
aplicados apenas ao tráfego RFC1918.
Rotas
Pode utilizar as tabelas de rotas para encaminhar o tráfego de saída da sua app para onde quiser. Por
predefinição, as tabelas de rotas apenas afetam o tráfego de destino RFC1918. Se definir
WEBSITE_VNET_ROUTE_ALL para 1, todas as suas chamadas de saída são afetadas. As rotas que estão definidas
na sua sub-rede de integração não afetarão respostas a pedidos de aplicações de entrada. Os destinos comuns
podem incluir dispositivos de firewall ou gateways.
Se quiser encaminhar todo o tráfego de saída no local, pode utilizar uma mesa de rota para enviar todo o
tráfego de saída para o seu gateway ExpressRoute. Se fizer a rota do tráfego para um gateway, certifique-se de
definir rotas na rede externa para enviar quaisquer respostas de volta.
As rotas do Border Gateway Protocol (BGP) também afetam o tráfego da sua aplicação. Se tiver rotas BGP a
partir de algo como um gateway ExpressRoute, o tráfego de saída da sua aplicação será afetado. Por padrão, as
rotas BGP afetam apenas o tráfego de destino RFC1918. Se WEBSITE_VNET_ROUTE_ALL estiver definido para 1,
todo o tráfego de saída pode ser afetado pelas suas rotas BGP.
Zonas Privadas Azure DNS
Depois de a sua aplicação se integrar com o seu VNet, utiliza o mesmo servidor DNS com o qual o seu VNet está
configurado. Por padrão, a sua aplicação não funcionará com as Zonas Privadas Azure DNS. Para trabalhar com
as Zonas Privadas Azure DNS, é necessário adicionar as seguintes definições de aplicações:
1. WEBSITE_DNS_SERVER com o valor 168.63.129.16
2. WEBSITE_VNET_ROUTE_ALL com o valor 1
Estas definições enviarão todas as suas chamadas de saída da sua app para o seu VNet, além de permitir que a
sua aplicação utilize zonas privadas Azure DNS.
Se quiser fazer chamadas para Private Endpoints,então tem de se integrar com as Zonas Privadas Azure DNS ou
gerir o ponto final privado no servidor DNS utilizado pela sua aplicação.
Como funciona a Integração Regional de VNet
As aplicações no Serviço de Aplicações estão hospedadas em funções de trabalhador. Os planos básicos e de
preços mais elevados são planos de hospedagem dedicados onde não existem cargas de trabalho de outros
clientes a funcionar nos mesmos trabalhadores. A Integração Regional de VNet funciona através da montagem
de interfaces virtuais com endereços na sub-rede delegada. Como o endereço está no seu VNet, pode aceder à
maioria das coisas dentro ou através do seu VNet como um VM no seu VNet. A implementação em rede é
diferente de executar um VM no seu VNet. É por isso que algumas funcionalidades de networking ainda não
estão disponíveis para esta funcionalidade.
Quando a Integração Regional de VNet está ativada, a sua aplicação faz chamadas de saída para a internet
através dos mesmos canais que o normal. Os endereços de saída listados no portal das propriedades da
aplicação são os endereços ainda utilizados pela sua aplicação. O que muda para a sua aplicação são as
chamadas para serviços de serviço seguros de ponto final, ou endereços RFC 1918 vão para o seu VNet. Se
WEBSITE_VNET_ROUTE_ALL estiver definido para 1, todo o tráfego de saída pode ser enviado para o seu VNet.
A funcionalidade suporta apenas uma interface virtual por trabalhador. Uma interface virtual por trabalhador
significa uma Integração VNet regional por plano de Serviço de Aplicação. Todas as aplicações do mesmo plano
de Serviço de Aplicações podem utilizar a mesma Integração VNet. Se precisar de uma aplicação para se ligar a
um VNet adicional, precisa de criar outro plano de Serviço de Aplicações. A interface virtual utilizada não é um
recurso a que os clientes tenham acesso direto.
Devido à natureza do funcionamento desta tecnologia, o tráfego que é usado com a Integração VNet não
aparece nos registos de fluxo da Rede Azure ou NSG.
Integração VNet exigida pelo Gateway

A Integração VNet exigida pelo Gateway suporta a ligação a um VNet noutra região ou a uma rede virtual
clássica. Integração VNet exigida pelo Gateway:
Permite que uma aplicação se conecte a apenas um VNet de cada vez.
Permite a integração de até cinco VNets num plano de Serviço de Aplicações.
Permite que o mesmo VNet seja usado por várias aplicações num plano de Serviço de Aplicações sem afetar
o número total que pode ser usado por um plano de Serviço de Aplicações. Se tiver seis aplicações usando o
mesmo VNet no mesmo plano de Serviço de Aplicações, isso conta como um VNet a ser usado.
Suporta um SLA de 99,9% devido ao SLA no gateway.
Permite que as suas aplicações utilizem o DNS com o qual o VNet está configurado.
Requer um gateway baseado em rede virtual configurado com uma VPN ponto-a-local SSTP antes de poder
ser ligado a uma aplicação.
Não pode utilizar a integração VNet exigida por gateways:
Com um VNet ligado ao Azure ExpressRoute.
De uma aplicação Linux
Para aceder ao ponto final do serviço, recursos seguros.
Com uma porta de entrada de coexistência que suporta tanto o ExpressRoute como as VPNs ponto-a-local ou
site-to-site.
Crie um portal na sua rede virtual Azure
Para criar uma porta de entrada:
1. Crie uma sub-rede de gateway no seu VNet.
2. Crie o gateway VPN. Selecione um tipo VPN baseado em rota.
3. Desaponte os endereços ponto a local. Se o gateway não estiver no SKU básico, então o IKEV2 deve ser
desativado na configuração ponto-a-local e o SSTP deve ser selecionado. O espaço de endereço ponto-a-
local deve estar nos blocos de endereços RFC 1918 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16.
Se criar o portal para utilização com a Integração VNet do Serviço de Aplicações, não precisa de carregar um
certificado. Criar o portal pode demorar 30 minutos. Não poderá integrar a sua aplicação com o seu VNet até
que o gateway seja aprovisionado.
Como funciona a integração VNet exigida por gateways
A Integração VNet exigida pelo Gateway é construída em cima da tecnologia VPN ponto-a-local. As VPNs ponto-
a-local limitam o acesso à rede à máquina virtual que acolhe a aplicação. As aplicações são restritas para enviar
tráfego para a internet apenas através de Conexões Híbridas ou através da Integração VNet. Quando a sua
aplicação está configurada com o portal para utilizar a Integração VNet exigida por gateways, uma negociação
complexa é gerida em seu nome para criar e atribuir certificados no gateway e no lado da aplicação. O resultado
é que os trabalhadores utilizados para hospedar as suas apps são capazes de ligar diretamente ao gateway de
rede virtual no VNet selecionado.
Acesso aos recursos no local

As aplicações podem aceder aos recursos no local, integrando-se com VNets que têm ligações site-to-site. Se
utilizar a Integração VNet exigida por gateways, atualize as suas rotas de gateway VPN no local com os seus
blocos de endereços ponto-a-local. Quando a VPN site-to-site é configurada pela primeira vez, os scripts
utilizados para configurar as rotas devem configurar as rotas corretamente. Se adicionar os endereços ponto-a-
local depois de criar a VPN do site, tem de atualizar as rotas manualmente. Detalhes sobre como fazer isso
variam por gateway e não são descritos aqui. Não pode ter bGP configurado com uma ligação VPN site-to-site.
Não é necessária nenhuma configuração adicional para que a funcionalidade regional de Integração VNet atinja
através do seu VNet para recursos no local. Basta ligar o seu VNet aos recursos no local, utilizando o
ExpressRoute ou uma VPN site-to-site.
NOTE
A funcionalidade de Integração VNet exigida por gateway não integra uma aplicação com um VNet que tenha um gateway
ExpressRoute. Mesmo que o gateway ExpressRoute esteja configurado em modo de coexistência,a Integração VNet não
funciona. Se precisar de aceder aos recursos através de uma ligação ExpressRoute, utilize a funcionalidade regional de
Integração VNet ou um Ambiente de Serviço de Aplicações, que funciona no seu VNet.
Peering
Se utilizar o seu olhar com a Integração Regional de VNet, não precisa de fazer nenhuma configuração adicional.
Se utilizar a Integração VNet exigida por gateways com o seu espremia, tem de configurar alguns itens
adicionais. Para configurar olhando para trabalhar com a sua aplicação:
1. Adicione uma ligação de espreitar no VNet a que a sua aplicação se conecta. Ao adicionar a ligação de pares,
ative o acesso à rede vir tual e selecione Deixe o tráfego reencaminhado e permita o trânsito de
gateway .
2. Adicione uma ligação de observação no VNet que está a ser espreitada para o VNet a que está ligado.
Quando adicionar a ligação de espreitamento no destino VNet, ative o acesso à rede vir tual e selecione
Deixe o tráfego reencaminhado e permita gateways remotos .
3. Aceda ao plano de Ser viço de > Aplicações networking > VNet Integration UI no portal. Selecione o
VNet a que a sua aplicação se conecta. Na secção de encaminhamento, adicione o intervalo de endereços do
VNet que está espreguiçadado com o VNet a que a sua aplicação está ligada.
Gerir a integração vNet

A ligação e desconexão com um VNet encontra-se ao nível da aplicação. As operações que podem afetar a
integração do VNet em várias aplicações estão ao nível do plano do Serviço de Aplicações. A partir da aplicação
> portal de > Integração VNet em rede, pode obter detalhes sobre o seu VNet. Pode ver informações
semelhantes ao nível do plano do Serviço de Aplicações no portal de Integração VNet do plano de serviço de >
Networking > VNet Integration aplicações.
A única operação que pode ter na visão da aplicação da sua instância de Integração VNet é desligar a sua
aplicação do VNet a que está atualmente ligada. Para desligar a sua aplicação de um VNet, selecione
Disconnect . A sua aplicação é reiniciada quando desliga de um VNet. Desligar não muda o seu VNet. A sub-
rede ou gateway não é removida. Se quiser então eliminar o seu VNet, desligue primeiro a sua aplicação do
VNet e elimine os recursos nele, como os gateways.
O plano de Serviço de Aplicações VNet Integration UI mostra-lhe todas as integrações VNet utilizadas pelas
aplicações no seu plano de Serviço de Aplicações. Para ver detalhes em cada VNet, selecione o VNet em que está
interessado. Existem duas ações que pode realizar aqui para integração VNet exigida por gateway:
Rede sincronizada : A operação de rede de sincronização é utilizada apenas para a função de Integração
VNet dependente de gateways. A realização de uma operação de rede de sincronização garante que os seus
certificados e informações de rede estão sincronizados. Se adicionar ou alterar o DNS do seu VNet, efetue
uma operação de rede de sincronização. Esta operação reinicia quaisquer aplicações que utilizem este VNet.
Esta operação não funcionará se estiver a utilizar uma app e um vnet pertencentes a diferentes subscrições.
Adicionar rotas : Adicionar rotas conduz o tráfego de saída para o seu VNet.
Encaminhamento de integração VNet exigido pela Porta de entrada
As rotas definidas no seu VNet são usadas para direcionar o tráfego para o seu VNet a partir da sua aplicação.
Para enviar tráfego adicional de saída para o VNet, adicione os blocos de endereços aqui. Esta capacidade
funciona apenas com a integração VNet exigida por gateways. As tabelas de rotas não afetam o tráfego da sua
aplicação quando utiliza a Integração VNet exigida pelo gateway da forma que fazem com a Integração Regional
de VNet.
Certificados de integração VNet exigidos pelo Gateway
Quando a integração VNet exigida pelo gateway está ativada, há uma troca obrigatória de certificados para
garantir a segurança da ligação. Juntamente com os certificados estão a configuração de DNS, rotas e outras
coisas semelhantes que descrevem a rede.
Se os certificados ou informações de rede forem alterados, selecione Sync Network . Quando seleciona a Sync
Network , causa uma breve interrupção na conectividade entre a sua aplicação e o seu VNet. Embora a sua
aplicação não seja reiniciada, a perda de conectividade pode fazer com que o seu site não funcione
corretamente.
Detalhes dos preços

A funcionalidade regional de Integração VNet não tem qualquer custo adicional para utilização para além dos
custos de preços do plano de preços do App Service.
Três encargos estão relacionados com a utilização da funcionalidade de Integração VNet exigida por gateway:
Taxas de preços do plano app : As suas aplicações precisam de estar num plano de Serviço de Aplicações
Standard, Premium ou PremiumV2. Para obter mais informações sobre estes custos, consulte os preços do
Custos de transferência de dados : Há um custo para a saída de dados, mesmo que o VNet esteja no
mesmo centro de dados. Estes encargos são descritos em detalhes de preços de transferência de dados.
Custos de gateway VPN : Há um custo para o gateway de rede virtual que é necessário para a VPN ponto-
a-local. Para obter mais informações, consulte os preços da porta de entrada VPN.
A funcionalidade é fácil de configurar, mas isso não significa que a sua experiência será livre de problemas. Se
encontrar problemas de acesso ao ponto final pretendido, existem alguns utilitários que pode utilizar para testar
a conectividade a partir da consola de aplicações. Há duas consolas que podes usar. Uma é a consola Kudu, e a
outra é a consola no portal Azure. Para chegar à consola Kudu a partir da sua aplicação, vá a Tools > Kudu . Você
também pode chegar à consola Kudo em [sitename].scm.azurewebsites.net. Depois de o site carregar, vá ao
separador de consola Debug. Para chegar à consola azure hospedada pelo portal a partir da sua aplicação, vá
para tools > console .
Ferramentas
As ferramentas ping , nslookup , e tracer t não funcionarão através da consola devido a restrições de segurança.
Para preencher o vazio, são adicionadas duas ferramentas separadas. Para testar a funcionalidade DNS,
adicionámos uma ferramenta chamada nameresolver.exe . A sintaxe é:
nameresolver.exe hostname [optional: DNS Server]
Pode utilizar nameresolver para verificar os nomes de anfitriões de que a sua aplicação depende. Desta forma,
pode testar se tem algo mal configurado com o seu DNS ou talvez não tenha acesso ao seu servidor DNS. Pode
ver o servidor DNS que a sua aplicação utiliza na consola olhando para as variáveis ambientais
WEBSITE_DNS_SERVER e WEBSITE_DNS_ALT_SERVER.
Pode utilizar a ferramenta seguinte para testar a conectividade TCP com uma combinação de hospedeiro e porta.
Esta ferramenta chama-se tcpping e a sintaxe é:
tcpping.exe hostname [optional: port]
O utilitário tcpping diz-lhe se pode chegar a um hospedeiro específico e porto. Só pode mostrar sucesso se
houver uma aplicação a ouvir a combinação de anfitriões e portas, e há acesso de rede da sua app ao anfitrião
especificado e à porta.
Depuração de acesso a recursos de rede virtuais hospedados em rede
Várias coisas podem impedir que a sua aplicação chegue a um anfitrião específico e à porta. A maior parte do
tempo é uma destas coisas:
Uma firewall está no caminho. Se tiver uma firewall no caminho, atinja o intervalo do TCP. O tempo de
saída do TCP é de 21 segundos neste caso. Utilize a ferramenta de tcpping para testar a conectividade. Os
intervalos de tCP podem ser causados por muitas coisas além das firewalls, mas comecem por aí.
DNS não é acessível. O tempo de saída do DNS é de 3 segundos por servidor DNS. Se tiver dois
servidores DNS, o tempo é de 6 segundos. Use nameresolver para ver se o DNS está funcionando. Não pode
usar o nslookup, porque isso não usa o DNS com o qual a sua rede virtual está configurada. Se não for
acessível, pode ter uma firewall ou NSG bloqueando o acesso ao DNS ou pode estar em baixo.
Se esses itens não responderem aos seus problemas, procure primeiro coisas como:
O seu destino é um endereço não RFC1918 e não tem WEBSITE_VNET_ROUTE_ALL definido para 1?
Existe algum nSG bloqueando a saída da sua subnet de integração?
Se estiver a atravessar o Azure ExpressRoute ou uma VPN, o seu portal no local está configurado para
encaminhar o tráfego de volta para Azure? Se conseguir chegar a pontos finais na sua rede virtual, mas não
no local, verifique as suas rotas.
Tem permissão suficiente para definir delegação na subnet de integração? Durante a configuração regional
de Integração VNet, a sua subnet de integração é delegada na Microsoft.Web. O VNet Integration UI delega a
subnet para Microsoft.Web automaticamente. Se a sua conta não tiver permissões de networking suficientes
para definir a delegação, precisará de alguém que possa definir atributos na sua subnet de integração para
delegar a subnet. Para delegar manualmente a subnet de integração, vá à subnet UI da rede virtual Azure e
desloque a delegação para microsoft.Web.
Integração VNet exigida por gateway
O intervalo de endereços ponto-a-local nas gamas RFC 1918 (10.0.0.0.0.0-10.255.255.255 / 172.16.0.0-
172.31.255.255 / 192.168.0-192.168.255.255)?
O portal mostra como estando no portal? Se o seu portal está para baixo, então traga-o de volta para cima.
Os certificados mostram estar sincronizado, ou suspeita que a configuração da rede foi alterada? Se os seus
certificados estiverem dessincronizados ou suspeitar que foi feita uma alteração na configuração da sua rede
virtual que não foi sincronizada com os seus ASPs, selecione Sync Network .
Se estiver a atravessar uma VPN, a porta de entrada no local está configurada para encaminhar o tráfego de
volta para Azure? Se conseguir chegar a pontos finais na sua rede virtual, mas não no local, verifique as suas
rotas.
Está a tentar usar um portal de coexistência que suporta tanto o ponto de ponta como o ExpressRoute? Os
gateways de coexistência não são suportados com a Integração VNet.
Depurar problemas de networking é um desafio porque você não pode ver o que está bloqueando o acesso a
uma combinação específica de hospedeiro:porta. Algumas causas incluem:
Tem uma firewall no seu anfitrião que impede o acesso à porta de aplicação a partir da sua gama IP ponto-a-
local. A travessia das subredes requer frequentemente acesso público.
O seu anfitrião alvo está abatido.
A sua candidatura está em baixo.
Tinhao IP errado ou nome de anfitrião.
A sua aplicação está a ouvir num porto diferente do que esperava. Pode comparar o seu ID de processo com
a porta de audição utilizando "netstat -aon" no hospedeiro final.
Os seus grupos de segurança de rede estão configurados de forma a impedir o acesso ao seu anfitrião de
aplicação e porta a partir da sua gama IP ponto-a-local.
Não sabe qual o endereço que a sua aplicação realmente usa. Pode ser qualquer endereço na subnet de
integração ou no intervalo de endereços ponto-a-local, por isso precisa de permitir o acesso a partir de toda a
gama de endereços.
Os passos adicionais de depuração incluem:
Ligue-se a um VM na sua rede virtual e tente chegar ao seu anfitrião de recursos:porta a partir daí. Para
testar o acesso à TCP, utilize a ligação de teste de comando PowerShell . A sintaxe é:
test-netconnection hostname [optional: -Port]
Traga uma aplicação num VM e teste o acesso a esse anfitrião e à porta a partir da consola através da
utilização de tcpping .
Recursos no local
Se a sua aplicação não conseguir contactar um recurso no local, verifique se consegue contactar o recurso da
sua rede virtual. Utilize o comando PowerShell de ligação de rede de teste para verificar se há acesso tCP. Se
o seu VM não conseguir contactar o seu recurso no local, a sua ligação VPN ou ExpressRoute pode não estar
configurada corretamente.
Se o seu VM virtual hospedado em rede pode chegar ao seu sistema no local, mas a sua aplicação não pode, a
causa é provavelmente uma das seguintes razões:
As suas rotas não estão configuradas com a sua subnet ou intervalos de endereços ponto-a-local no seu
gateway no local.
Os seus grupos de segurança de rede estão a bloquear o acesso à sua gama IP ponto-a-site.
As suas firewalls no local estão a bloquear o tráfego da sua gama IP ponto-a-local.
Está a tentar chegar a um endereço não RFC 1918 utilizando a funcionalidade regional de Integração VNet.
Automatização
O suporte CLI está disponível para integração regional de VNet. Para aceder aos seguintes comandos, instale o
Azure CLI.
az webapp vnet-integration --help
Group
az webapp vnet-integration : Methods that list, add, and remove virtual network integrations
from a webapp.
Commands:
add : Add a regional virtual network integration to a webapp.
list : List the virtual network integrations on a webapp.
remove : Remove a regional virtual network integration from webapp.
az appservice vnet-integration --help
Group
az appservice vnet-integration : A method that lists the virtual network integrations used in an
appservice plan.
Commands:
list : List the virtual network integrations used in an appservice plan.
Para a integração VNet exigida por gateways, pode integrar o Serviço de Aplicações com uma rede virtual Azure
utilizando o PowerShell. Para um script pronto a executar, consulte uma aplicação no Azure App Service a uma
rede virtual Azure.
Configure ficheiros Azure num recipiente do
Windows no serviço de aplicações
NOTE
Este artigo aplica-se a recipientes windows personalizados. Para ser implantado no Serviço de Aplicações no Linux, consulte o
Serve Content do Armazenamento Azure.
Este guia mostra como aceder ao Armazenamento Azure em Recipientes Windows. Apenas as ações de ficheiros
Azure e as ações premium são suportadas. Usa ações de ficheiros Azure neste como. Os benefícios incluem
conteúdo seguro, portabilidade de conteúdo, acesso a várias aplicações e múltiplos métodos de transferência.
Pré-requisitos
Azure CLI (2.0.46 ou mais tarde).
Uma aplicação existente para recipientes windows no Serviço de Aplicações Azure
Criar partilha de ficheiros Azure
Upload de ficheiros para partilha de Ficheiros Azure
NOTE
O Azure Files é um armazenamento não predefinido e faturado separadamente, não incluído na aplicação web. Não suporta
usar a configuração firewall devido a limitações de infraestrutura.
Limitações
O Armazenamento Azure em contentores Windows encontra-se em pré-visualização e não supor ta dos
cenários de produção.
O Armazenamento Azure em recipientes Windows suporta a montagem apenas de recipientes Azure Files
(Ler / Escrever).
O Armazenamento Azure em contentores Windows não é supor tado para trazer os seus próprios cenários de
código nos planos do Serviço de Aplicações windows.
O Armazenamento Azure em contentores Windows não supor ta utilizar a configuração de Firewall de
Armazenamento devido a limitações de infraestrutura.
O Armazenamento Azure em recipientes Windows permite especificar até cinco pontos de montagem por app.
O Armazenamento Azure montado numa aplicação não é acessível através de pontos finais ftp/FTPs do Serviço
de Aplicação. Utilize o explorador de armazenamento Azure.
O Azure Storage é faturado de forma independente e não incluído na sua aplicação web. Saiba mais sobre os
preços do Armazenamento Azure.
Link armazenamento para a sua aplicação web (pré-visualização)

Para montar um Azure Files Share para um diretório az webapp config storage-account add na sua aplicação App
Service, utiliza o comando. O Tipo de Armazenamento deve ser AzureFiles.
az webapp config storage-account add --resource-group <group_name> --name <app_name> --custom-id <custom_id> --
storage-type AzureFiles --share-name <share_name> --account-name <storage_account_name> --access-key "
<access_key>" --mount-path <mount_path_directory of form c:<directory name> >
Deve fazer isto por quaisquer outros diretórios que queira estar ligado a uma partilha de Ficheiros Azure.
Verificar
Uma vez que uma partilha de Ficheiros Azure esteja ligada a uma aplicação web, pode verificar isso executando o
seguinte comando:
az webapp config storage-account list --resource-group <resource_group> --name <app_name>
Passos seguintes
Migrar uma aplicação ASP.NET para o Serviço de Aplicações Azure utilizando um recipiente Windows (Pré-
visualização).
Execute a sua aplicação no Serviço de Aplicações
Azure diretamente de um pacote ZIP
No Azure App Service,pode executar as suas aplicações diretamente a partir de um ficheiro de pacote ZIP de
implementação. Este artigo mostra como ativar esta funcionalidade na sua aplicação.
Todos os outros métodos de implementação no App Service têm algo em comum: os seus ficheiros são
implantados para D:\home\site\wwwroot na sua app (ou /home/site/wwwroot para aplicações Linux). Uma vez
que o mesmo diretório é utilizado pela sua app em tempo de execução, é possível que a implementação falhe
devido a conflitos de bloqueio de ficheiros, e para que a app se compore de forma imprevisível porque alguns
dos ficheiros ainda não estão atualizados.
Em contrapartida, quando se executa diretamente de um pacote, os ficheiros da embalagem não são copiados
para o diretório wwwroot. Em vez disso, o pacote ZIP em si é montado diretamente como o diretório wwwroot
apenas de leitura. Existem vários benefícios para correr diretamente a partir de um pacote:
Elimina os conflitos de bloqueio de ficheiros entre a implantação e o tempo de execução.
Garante que apenas as aplicações totalmente implementadas estão a funcionar a qualquer momento.
Pode ser implantado numa aplicação de produção (com reinício).
Melhora o desempenho das implementações do Gestor de Recursos Azure.
Pode reduzir os tempos de arranque a frio, particularmente para funções JavaScript com grandes árvores de
embalagem npm.
NOTE
Atualmente, apenas os ficheiros de pacotezip são suportados.
Criar um ficheiro ZIP do projeto

NOTE
Se descarregou os ficheiros num ficheiro ZIP, extrai os ficheiros primeiro. Por exemplo, se descarregou um ficheiro ZIP do
GitHub, não pode implementar esse ficheiro como está. O GitHub adiciona diretórios aninhados adicionais, que não
funcionam com o App Service.
Numa janela de terminal local, navegue para o diretório raiz do seu projeto de aplicação.
Este diretório deve conter o ficheiro de entrada na sua aplicação web, tais como index.html, index.php, e app.js.
Também pode conter ficheiros de gestão de pacotes como project.json, composer.json, package.json, bower.json,
e requirements.txt.
A menos que pretenda que o Serviço de Aplicações execute npm bower a gulp composer automatização de
implementação para si, execute todas as tarefas de construção (por exemplo, , , e ) e pip certifique-se de que tem
todos os ficheiros necessários para executar a app. Este passo é necessário se quiser executar o seu pacote
diretamente.
Crie um arquivo ZIP de tudo no seu projeto. O comando seguinte utiliza a ferramenta predefinida no seu
terminal:
# Bash
zip -r <file-name>.zip .
# PowerShell
Compress-Archive -Path * -DestinationPath <file-name>.zip
Ativar o funcionamento do pacote

A WEBSITE_RUN_FROM_PACKAGE definição da aplicação permite a execução de um pacote. Para o definir, execute o
seguinte comando com o Azure CLI.
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings

WEBSITE_RUN_FROM_PACKAGE="1"
WEBSITE_RUN_FROM_PACKAGE="1" Permite-lhe executar a sua aplicação de um pacote local para a sua aplicação.
Também pode correr a partir de um pacote remoto.
Executar o pacote
The easiest way to run a package in your App Service is with the Azure CLI az webapp deployment source config-
zip command. Por exemplo:
az webapp deployment source config-zip --resource-group <group-name> --name <app-name> --src <filename>.zip
Como WEBSITE_RUN_FROM_PACKAGE a definição da aplicação está definida, este comando não extrai o conteúdo do
pacote para o d:\home\site\wwwroot diretório da sua app. Em vez disso, ele envia o ficheiro ZIP como é para
D:\home\data\SitePackages, e cria um nome de pacote.txt no mesmo diretório, que contém o nome do pacote
ZIP para carregar no tempo de execução. Se fizer o upload do seu pacote ZIP de uma forma diferente (como
FTP),tem de criar manualmente o diretório D:\home\data\SitePackages e o ficheiro packagename.txt
manualmente.
O comando também reinicia a aplicação. Como WEBSITE_RUN_FROM_PACKAGE está definido, o App Service monta o
pacote carregado como o diretório wwwroot apenas de leitura e executa a app diretamente a partir desse
diretório montado.
Executar a partir de URL externo em vez

Também pode executar uma embalagem a partir de um URL externo, como o Armazenamento De Blob Azure.
Pode utilizar o Azure Storage Explorer para fazer o upload de ficheiros de pacotes para a sua conta de
armazenamento Blob. Deve utilizar um recipiente de armazenamento privado com uma Assinatura de Acesso
Partilhado (SAS) para permitir que o tempo de execução do Serviço de Aplicações aceda de forma segura à
embalagem.
Assim que enviar o seu ficheiro para o armazenamento blob WEBSITE_RUN_FROM_PACKAGE e tiver um URL SAS para
o ficheiro, defina a definição da aplicação para o URL. O exemplo seguinte fá-lo utilizando o Azure CLI:

WEBSITE_RUN_FROM_PACKAGE="https://myblobstorage.blob.core.windows.net/content/SampleCoreMVCApp.zip?st=2018-
02-13T09%3A48%3A00Z&se=2044-06-14T09%3A48%3A00Z&sp=rl&sv=2017-04-
17&sr=b&sig=bNrVrEFzRHQB17GFJ7boEanetyJ9DGwBSV8OM3Mdh%2FM%3D"
Se publicar um pacote atualizado com o mesmo nome para o armazenamento Blob, precisa de reiniciar a sua
aplicação para que o pacote atualizado seja carregado no Serviço de Aplicações.
Correr diretamente de wwwroot um pacote faz apenas leitura. A sua aplicação receberá um erro se tentar
escrever ficheiros para este diretório.
Os formatos TAR e GZIP não são suportados.
Esta função não é compatível com cache local.
Para um melhor desempenho a frio, utilize WEBSITE_RUN_FROM_PACKAGE a opção Zip local (=1).
Mais recursos
Implantação contínua para o Serviço de Aplicações Azure
Implementar código com um ficheiro ZIP ou WAR
Implemente a sua aplicação para o Azure App
Service com um ficheiro ZIP ou WAR
Este artigo mostra-lhe como usar um ficheiro ZIP ou ficheiro WAR para implementar a sua aplicação web para o
Azure App Service.
Esta implementação de ficheiros ZIP utiliza o mesmo serviço Kudu que alimenta implementações contínuas
baseadas na integração. Kudu suporta a seguinte funcionalidade para a implementação de ficheiros ZIP:
Eliminação de ficheiros que sobrados de uma implantação anterior.
Opção de ativar o processo de construção predefinido, que inclui a restauração do pacote.
Personalização de implementação, incluindo scripts de implementação de execução.
Registos de implantação.
Um limite de tamanho de ficheiro de 2048 MB.
Para mais informações, consulte a documentação de Kudu.
A implementação de ficheiros WAR implementa o seu ficheiro WAR para o App Service para executar a sua
aplicação web Java. Ver Deploy WAR file.
Pré-requisitos
Para completar os passos deste artigo, crie uma app de Serviço de Aplicações, ou use uma app que criou para
outro tutorial.
Criar um ficheiro ZIP do projeto

NOTE
Se descarregou os ficheiros num ficheiro ZIP, extrai os ficheiros primeiro. Por exemplo, se descarregou um ficheiro ZIP do
GitHub, não pode implementar esse ficheiro como está. O GitHub adiciona diretórios aninhados adicionais, que não
funcionam com o App Service.
Numa janela de terminal local, navegue para o diretório raiz do seu projeto de aplicação.
Este diretório deve conter o ficheiro de entrada na sua aplicação web, tais como index.html, index.php, e app.js.
Também pode conter ficheiros de gestão de pacotes como project.json, composer.json, package.json, bower.json, e
requirements.txt.
A menos que pretenda que o Serviço de Aplicações execute npm bower a gulp composer automatização de
implementação para si, execute todas as tarefas de construção (por exemplo, , , e ) e pip certifique-se de que tem
todos os ficheiros necessários para executar a app. Este passo é necessário se quiser executar o seu pacote
diretamente.
Crie um arquivo ZIP de tudo no seu projeto. O comando seguinte utiliza a ferramenta predefinida no seu terminal:
# Bash
zip -r <file-name>.zip .
# PowerShell
Compress-Archive -Path * -DestinationPath <file-name>.zip
Implementar o ficheiro ZIP

No browser, navegue até https://<app_name>.scm.azurewebsites.net/ZipDeployUI .
Carregue o ficheiro ZIP que criou em Criar um ficheiro ZIP do projeto ao arrastar para a área do explorador de
ficheiros na página Web.
Quando a implementação está em curso, um ícone no canto superior direito mostra o progresso em percentagem.
A página também mostra as mensagens verbosas para a operação abaixo da área do explorador. Quando estiver
concluído, a última mensagem de implementação deverá dizer Deployment successful .
O ponto final acima não funciona para os Serviços de Aplicações Linux neste momento. Considere utilizar ftp ou a
API de implantação ZIP.
Implementar ficheiro ZIP com o Azure CLI

Implemente o ficheiro ZIP enviado para a sua aplicação web utilizando o comando config-zip de fonte de
implementação da webapp az.
O exemplo seguinte implementa o ficheiro ZIP que fez upload. Quando utilizar uma instalação local do Azure CLI,
--src especifique o caminho para o seu ficheiro ZIP local para .
az webapp deployment source config-zip --resource-group <group-name> --name <app-name> --src

clouddrive/<filename>.zip
Este comando implementa os ficheiros e os diretórios do ficheiro ZIP na pasta de aplicações do Serviço de
Aplicações predefinido ( \home\site\wwwroot ) e reinicia a aplicação.
Por padrão, o motor de implantação pressupõe que um ficheiro ZIP está pronto para funcionar como está e não
executa qualquer automatização de construção. Para permitir a mesma automatização de construção
SCM_DO_BUILD_DURING_DEPLOYMENT que numa implementação git,defina a definição da aplicação executando o
seguinte comando na Cloud Shell:
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings

SCM_DO_BUILD_DURING_DEPLOYMENT=true
Para mais informações, consulte a documentação de Kudu.
Implementar ficheiro ZIP com APIs REST

Pode utilizar o serviço de implementação REST APIs para implementar o ficheiro .zip para a sua aplicação em
Azure. Para implementar, envie um pedido post para https://<app_name>.scm.azurewebsites.net/api/zipdeploy. O
pedido DO POST deve conter o ficheiro .zip no corpo da mensagem. As credenciais de implementação para a sua
aplicação são fornecidas no pedido através da autenticação básica HTTP. Para mais informações, consulte a
referência de implantação de impulso .zip.
Para a autenticação HTTP BASIC, precisa das suas credenciais de implementação do Serviço de Aplicações. Para ver
como definir as suas credenciais de implementação, consulte Definir e redefinir as credenciais de nível de
utilizador.
Com cURL
O exemplo seguinte utiliza a ferramenta cURL para implantar um ficheiro .zip. Substitua os <deployment_user>
espaços <zip_file_path> reservados, e <app_name> . Quando solicitado por cURL, digite a palavra-passe.
curl -X POST -u <deployment_user> --data-binary @"<zip_file_path>"

https://<app_name>.scm.azurewebsites.net/api/zipdeploy
Este pedido aciona a colocação de pressão a partir do ficheiro .zip carregado. Pode rever as implementações atuais
https://<app_name>.scm.azurewebsites.net/api/deployments e passadas utilizando o ponto final, como mostra o
exemplo cURL seguinte. Mais uma <app_name> vez, substitua-o pelo nome da sua aplicação e <deployment_user>
pelo nome de utilizador das suas credenciais de implementação.
curl -u <deployment_user> https://<app_name>.scm.azurewebsites.net/api/deployments
Com o PowerShell
O exemplo seguinte utiliza o upload do Ficheiro .zip Publish-AzWebapp. Substitua os <group-name> espaços
<app-name> reservados, e <zip-file-path> .
Publish-AzWebapp -ResourceGroupName <group-name> -Name <app-name> -ArchivePath <zip-file-path>
Este pedido aciona a colocação de pressão a partir do ficheiro .zip carregado.

Para rever as atuais e passadas implantações, execute os seguintes comandos. Mais uma <deployment-user> vez,
substitua os espaços <deployment-password> reservados. <app-name>
$username = "<deployment-user>"
$password = "<deployment-password>"
$apiUrl = "https://<app-name>.scm.azurewebsites.net/api/deployments"
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username,
$password)))
$userAgent = "powershell/1.0"
Invoke-RestMethod -Uri $apiUrl -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)} -UserAgent
$userAgent -Method GET
Implementar ficheiro WAR

Para implementar um ficheiro WAR para o https://<app-name>.scm.azurewebsites.net/api/wardeploy Serviço de
Aplicações, envie um pedido post para . O pedido POST tem de conter o ficheiro .war no corpo da mensagem. As
credenciais de implementação para a sua aplicação são fornecidas no pedido através da autenticação básica HTTP.
Utilize /api/wardeploy sempre ao implementar ficheiros WAR. Esta API expandirá o seu ficheiro WAR e colocá-lo-á
na unidade de ficheiros partilhados. a utilização de outras APIs de implantação pode resultar em comportamento
inconsistente.
Para a autenticação HTTP BASIC, precisa das suas credenciais de implementação do Serviço de Aplicações. Para ver
como definir as suas credenciais de implementação, consulte Definir e redefinir as credenciais de nível de
utilizador.
Com cURL
O exemplo seguinte utiliza a ferramenta cURL para implantar um ficheiro .war. Substitua os <username> espaços
<war-file-path> reservados, e <app-name> . Quando solicitado por cURL, digite a palavra-passe.
curl -X POST -u <username> --data-binary @"<war-file-path>" https://<app-
name>.scm.azurewebsites.net/api/wardeploy
Com o PowerShell
O exemplo seguinte utiliza o upload do Ficheiro .war Publish-AzWebapp. Substitua os <group-name> espaços
<app-name> reservados, e <war-file-path> .
Publish-AzWebapp -ResourceGroupName <group-name> -Name <app-name> -ArchivePath <war-file-path>
O que acontece com a minha aplicação durante a implementação?

Todos os métodos de implementação oficialmente /home/site/wwwroot suportados fazem alterações nos ficheiros
na pasta da sua aplicação. Estes ficheiros são utilizados para executar a sua aplicação. Portanto, a implementação
pode falhar por causa de ficheiros bloqueados. A aplicação também pode comportar-se de forma imprevisível
durante a implementação, porque nem todos os ficheiros atualizados ao mesmo tempo. Isto é indesejável para
uma aplicação virada para o cliente. Existem algumas maneiras diferentes de evitar estas questões:
Execute a sua aplicação a partir do pacote ZIP diretamente sem desempacotá-la.
Pare a sua aplicação ou ative o modo offline para a sua aplicação durante a implementação. Para mais
informações, consulte Lidar com ficheiros bloqueados durante a implementação.
Desloque-se para uma ranhura de preparação com troca de automóveis ativada.
Passos seguintes
Para cenários de implantação mais avançados, tente implantar-se para Azure com Git. A implantação baseada em
Git para o Azure permite o controlo da versão, restauro de pacotes, MSBuild e muito mais.
Mais recursos
Kudu: Implantação de um ficheiro zip
Credenciais de implantação do serviço de aplicações Azure
Implemente a sua aplicação para o Serviço de
Aplicações Azure utilizando FTP/S
Este artigo mostra-lhe como usar FTP ou FTPS para implementar a sua aplicação web, backend de aplicações
móveis ou app API para o Azure App Service.
O ponto final ftp/S para a sua aplicação já está ativo. Nenhuma configuração é necessária para permitir a
implantação ftp/S.
Painel de instrumentos FTP aberto

1. No portal Azure,procure e selecione Serviços de Aplicações.
2. Selecione a aplicação web que pretende implementar.

3. Selecione central > de implantaçãoFTP > Dashboard .
Obtenha informações de ligação FTP

No painel ftp, selecione Copy para copiar as credenciais de ponto final ftps e app.
Recomenda-se que utilize credenciais de aplicação para implementar na sua aplicação porque é única em cada
aplicação. No entanto, se clicar em Credenciais de Utilizador, pode definir credenciais de nível de utilizador que
pode utilizar para login FTP/S em todas as aplicações do Serviço de Aplicações na sua subscrição.
NOTE
Autenticar para um ponto final FTP/FTPS utilizando credenciais de nível de utilizador requer um nome de utilizador no
seguinte formato:
<app-name>\<user-name>
Uma vez que as credenciais de nível de utilizador estão ligadas ao utilizador e não a um recurso específico, o nome de
utilizador deve estar neste formato para direcionar a ação de início de sessão para o ponto final da aplicação certa.
Implementar ficheiros para o Azure

1. Do seu cliente FTP (por exemplo, Visual Studio, Cyberduck,ou WinSCP), utilize as informações de ligação que
recolheu para se ligar à sua aplicação.
2. Copie os seus ficheiros e respetiva estrutura de diretório para o diretório /site/wwwroot em Azure (ou o
/site/wwwroot/App_Data/Jobs/ diretório para WebJobs).
3. Navegue no URL da sua aplicação para verificar se a aplicação está a funcionar corretamente.
NOTE
Ao contrário das implementações baseadas em Git,a implantação ftp não suporta as seguintes automatizações de
implantação:
dependência restaura (tais como nuGet, NPM, PIP e automações de compositor)
compilação de binários .NET
geração de web.config (aqui é um exemplo de Node.js)
Gere estes ficheiros necessários manualmente na sua máquina local e, em seguida, implemente-os juntamente com a sua
aplicação.
Impor FTPS
Para uma maior segurança, deve permitir ftp apenas sobre TLS/SSL. Também pode desativar tanto o FTP como o
FTPS se não utilizar a implantação ftp.
Na página de recursos da sua aplicação no portal Azure,selecioneconfigurações gerais de configuração > a
partir da navegação à esquerda.
Para desativar o FTP não encriptado, selecione FTPS apenas no estado FTP . Para desativar totalmente o FTP e
o FTPS, selecione Desativado . Quando terminar, clique em Guardar . Se utilizar apenas ftps, deve impor TLS
1.2 ou superior, navegando para a lâmina de definições TLS/SSL da sua aplicação web. Os TLS 1.0 e 1.1 não
são suportados apenas com FTPS .
Para a implementação de FTP utilizando o Azure CLI,consulte Criar uma aplicação web e implementar ficheiros
com FTP (Azure CLI).
Para a implementação ftp utilizando o Azure PowerShell,consulte ficheiros upload para uma aplicação web
utilizando FTP (PowerShell).

Todos os métodos de implementação oficialmente /home/site/wwwroot suportados fazem alterações nos
ficheiros na pasta da sua aplicação. Estes ficheiros são utilizados para executar a sua aplicação. Portanto, a
implementação pode falhar por causa de ficheiros bloqueados. A aplicação também pode comportar-se de
forma imprevisível durante a implementação, porque nem todos os ficheiros atualizados ao mesmo tempo. Isto
é indesejável para uma aplicação virada para o cliente. Existem algumas maneiras diferentes de evitar estas
questões:
Implantação de FTP de resolução de problemas

Como posso resolver a implantação de FTP?
Não posso publicar o meu código. Como posso resolver o problema?
Como posso ligar-me ao FTP no Azure App Service através do modo passivo?
Como posso resolver a implantação de FTP?
O primeiro passo para a resolução de problemas da implantação de FTP é isolar um problema de implantação
de um problema de aplicação em tempo de execução.
Um problema de implementação normalmente resulta em ficheiros ou ficheiros errados implantados na sua
aplicação. Pode resolver problemas investigando a sua implantação ftp ou selecionando um caminho de
implantação alternativo (como o controlo de fonte).
Um problema de aplicação em tempo de execução normalmente resulta no conjunto certo de ficheiros
implantados na sua aplicação, mas comportamento incorreto da aplicação. Você pode resolver problemas
focando-se no comportamento do código em tempo de execução e investigando caminhos específicos de falha.
Para determinar um problema de implantação ou tempo de execução, consulte problemas de implantação vs.
tempode execução .
I'm not able to FTP and publish my code. Como posso resolver o problema?
Verifique se inseriu o nome de anfitrião e as credenciais corretas. Verifique também se as seguintes portas FTP
na sua máquina não estão bloqueadas por uma firewall:
Porta de ligação de controlo de FTP: 21
Porta de ligação de dados FTP: 989, 10001-10300
Como posso ligar-me ao FTP no Azure App Service através do modo passivo?
O Azure App Service suporta a ligação através do modo Ativo e Passivo. O modo passivo é preferido porque as
suas máquinas de implantação estão geralmente por detrás de uma firewall (no sistema operativo ou como
parte de uma rede doméstica ou empresarial). Veja um exemplo da documentação winscp.
Passos seguintes
Para cenários de implantação mais avançados, tente implantar-se para Azure com Git. A implantação baseada
em Git para o Azure permite o controlo da versão, restauro de pacotes, MSBuild e muito mais.
Mais recursos
Credenciais de implantação do serviço de aplicações Azure
Sincronizar conteúdo de uma pasta de nuvem para o
Este artigo mostra-lhe como sincronizar o seu conteúdo com o Serviço de Aplicações Azure a partir do Dropbox e
do OneDrive.
A implantação de sincronização de conteúdo sonoro a pedido é alimentada pelo motor de implantação Do Serviço
de Aplicação Kudu. Pode trabalhar com o seu código de aplicações e conteúdo numa pasta de nuvem designada e,
em seguida, sincronizar para o Serviço de Aplicações com o clique de um botão. A sincronização de conteúdo
utiliza o servidor de construção Kudu.
Ativar a implementação da sincronização de conteúdos

Para ativar a sincronização de conteúdos, navegue para a página da sua aplicação Do Serviço de Aplicações no
portal Azure.
No menu esquerdo, clique no Centro > de ImplementaçãoOneDrive ou Dropbox > Autorizar . Siga os pedidos
de autorização.
Só precisa de autorizar com o OneDrive ou o Dropbox uma vez. Se já estiver autorizado, basta clicar em
Continuar . Pode alterar a conta OneDrive ou Dropbox autorizada clicando na conta Change .
Na página Configure, selecione a pasta que pretende sincronizar. Esta pasta é criada sob o seguinte caminho de
conteúdo designado no OneDrive ou Dropbox.
OneDrive : Apps\Azure Web Apps
Dropbox : Apps\Azure
Quando terminar, clique em Continuar .
Na página Resumo, verifique as suas opções e clique em Terminar .
Sincronizar conteúdo
Quando pretender sincronizar conteúdo na sua pasta de nuvem com o Serviço de Aplicações, volte à página do
Centro de Implementação e clique em Sync .
NOTE
Devido às diferenças subjacentes nas APIs, o OneDrive for Business não é suportado neste momento.
Desativar a implementação da sincronização de conteúdos

Para desativar a sincronização de conteúdos, navegue para a página da sua aplicação do App Service no portal
Azure.
No menu esquerdo, clique em > Desligar o Centro de Implantação .
Todos os métodos de implementação oficialmente /home/site/wwwroot suportados fazem alterações nos ficheiros
na pasta da sua aplicação. Estes ficheiros são utilizados para executar a sua aplicação. Portanto, a implementação
pode falhar por causa de ficheiros bloqueados. A aplicação também pode comportar-se de forma imprevisível
durante a implementação, porque nem todos os ficheiros atualizados ao mesmo tempo. Isto é indesejável para
uma aplicação virada para o cliente. Existem algumas maneiras diferentes de evitar estas questões:
Passos seguintes
Desdobre-se a partir de Git repo local
Implantação contínua para o Serviço de Aplicações
Azure
O Serviço de Aplicações Azure permite a implantação contínua dos repositórios GitHub, BitBucket e Azure Repos,
puxando as últimas atualizações. Este artigo mostra-lhe como usar o portal Azure para implantar continuamente
a sua app através do serviço de construção Kudu ou dos Oleodutos Azure.
Para obter mais informações sobre os serviços de controlo de fontes, consulte [Criar um repo (GitHub)], [Criar
um repo (BitBucket)]ou [Criar um novo Repo Git (Azure Repos)].
Prepare o seu repositório

Para obter construções automáticas do servidor de construção de Software de Aplicações Azure Kudu, certifique-
se de que a sua raiz de repositório tem os ficheiros corretos no seu projeto.
RUN T IM E F IC H EIRO S DE DIRETÓ RIO DE RA IZ
ASP.NET (apenas janelas) *.sln, *.csproj, ou padrão.aspx
Núcleo de ASP.NET *.sln ou *.csproj
PHP index.php
Rubi (apenas Linux) Gemfile
Node.js server.js, app.js, ou package.json com um script inicial
Python .py, requirements.txt, or runtime.txt _ *
HTML default.htm, default.html, default.asp, index.htm, index.html,

or iisstart.htm
Trabalhos Web <job_name>/correr.>< de extensão em dados de

_aplicações/empregos/contínuos para WebJobs contínuos, ou
Dados de Aplicações/empregos/desencadeados_ para
WebJobs desencadeados. Para mais informações, consulte a
documentação do Kudu WebJobs.
Funções Ver implantação contínua para funções Azure.
Para personalizar a sua implementação, inclua um ficheiro .deployment na raiz do repositório. Para mais
informações, consulte personalizar implementações e script de implementação personalizado.
NOTE
Se desenvolver no Visual Studio, deixe o Visual Studio criar um repositório para si. O projeto está imediatamente pronto
para ser implementado usando Git.
Autorizar o Serviço de Aplicações Azure
Para utilizar o Azure Repos, certifique-se de que a sua organização Azure DevOps está ligada à sua subscrição
Azure. Para mais informações, consulte A configuração de uma conta Azure DevOps Servicespara que possa ser
implementada para uma aplicação web .
Para bitbucket ou GitHub, autorize o Serviço de Aplicações Azure a ligar-se ao seu repositório. Só precisa
autorizar com um serviço de controlo de fontes uma vez.
1. No portal Azure,procure serviços de aplicações e selecione.
2. Selecione o Serviço de Aplicações que pretende implementar.
3. Na página da aplicação, selecione Deployment Center no menu esquerdo.

4. Na página do Centro de Implementação, selecione GitHub ou Bitbucket, e, em seguida, selecione
Autorizar .
5. Inscreva-se no serviço se necessário e siga as indicações de autorização.
Ativar a implementação contínua

Depois de autorizar um serviço de controlo de fontes, configure a sua aplicação para uma implementação
contínua através do servidor de construção de apps Kudu incorporado, ou através de Pipelines Azure.
Opção 1: Serviço de Aplicações Kudu
Pode utilizar o servidor de construção de aplicativos Kudu incorporado para implantar continuamente a partir de
GitHub, Bitbucket ou Azure Repos.
1. No portal Azure,procure serviços de aplicações e, em seguida, selecione o Serviço de Aplicações que
pretende implementar.
3. Selecione o seu fornecedor de controlo de fonte autorizado na página do Centro de Implementação e
selecione Continuar . Para GitHub ou Bitbucket, também pode selecionar a conta Alterar para alterar a
conta autorizada.
NOTE
Para utilizar o Azure Repos, certifique-se de que a sua organização Azure DevOps Services está ligada à sua
subscrição Azure. Para mais informações, consulte A configuração de uma conta Azure DevOps Servicespara que
possa ser implementada para uma aplicação web .
4. Para o GitHub ou Azure Repos, na página do fornecedor Build, selecione o serviço de construção do
Ser viço de Aplicações, e depois selecione Continuar . O Bitbucket usa sempre o serviço de construção
do Serviço de Aplicações.
5. Na página Configure:
Para o GitHub, desça e selecione a Organização , Repositório e Ramo que pretende implementar
continuamente.
NOTE
Se não vir quaisquer repositórios, poderá ter de autorizar o Azure App Service no GitHub. Navegue no seu
repositório GitHub e vá aAplicações OAuth autorizadas de > Definições. > Settings Selecione O
Serviço de Aplicações Azure e, em seguida, selecione Grant . Para os repositórios da organização, você
deve ser um proprietário da organização para conceder as permissões.
Para bitbucket, selecione a Equipa Bitbucket, repositório e Branch que pretende implementar
continuamente.
Para o Azure Repos, selecione a Organização Azure DevOps , Projeto, Repositório e Ramo que
pretende implementar continuamente.
NOTE
Se a sua organização Azure DevOps não estiver listada, certifique-se de que está ligada à sua subscrição
Azure. Para mais informações, consulte A configuração de uma conta Azure DevOps Servicespara que
possa ser implementada para uma aplicação web ..
6. Selecione Continuar .
7. Depois de configurar o fornecedor de construção, reveja as definições na página Resumo e, em seguida,
selecione Terminar .
8. Novos compromissos no repositório e sucursal selecionados agora implantam-se continuamente na sua
app App Service. Pode rastrear os compromissos e implementações na página do Centro de
Implantação.
Opção 2: Gasodutos Azure

Se a sua conta tiver as permissões necessárias, pode configurar os Gasodutos Azure para implantar
continuamente a partir do GitHub ou do Azure Repos. Para obter mais informações sobre a implementação
através dos Oleodutos Azure, consulte a Implementação de uma aplicação web parao Azure App Services .
Pré-requisitos
Para que o Serviço de Aplicações Azure crie entregas contínuas utilizando pipelines Azure, a sua organização
Azure DevOps deve ter as seguintes permissões:
A sua conta Azure deve ter permissões para escrever ao Azure Ative Directory e criar um serviço.
A sua conta Azure deve ter o papel de Proprietário na sua subscrição Azure.
Deve ser administrador no projeto Azure DevOps que pretende utilizar.
Gasodutos GitHub + Azure
3. Selecione gitHub como o fornecedor de controlo de fonte na página do Centro de Implementação e
selecione Continuar . Para o GitHub, pode selecionar a Conta De Alteração para alterar a conta
autorizada.
4. Na página 'Fornecedor de Construção', selecione Pipelines Azure (Pré-visualização) , e, em

seguida, selecione Continuar .
5. Na página Configure, na secção Código, selecione a Organização, Repositório e Ramo que pretende
implementar continuamente e selecionar Continuar .
NOTE
Se não vir quaisquer repositórios, poderá ter de autorizar o Azure App Service no GitHub. Navegue no seu
repositório GitHub e vá aAplicações OAuth autorizadas de > Definições. > Settings Selecione O Serviço de
Aplicações Azure e, em seguida, selecione Grant . Para os repositórios da organização, você deve ser um
proprietário da organização para conceder as permissões.
Na secção Build, especifique a Organização Azure DevOps, Projeto, enquadramento linguístico que os
Oleodutos Azure devem usar para executar tarefas de construção e, em seguida, selecionar Continuar .

7. Novos compromissos no repositório e sucursal selecionados agora implantam-se continuamente no seu

Serviço de Aplicações. Pode rastrear os compromissos e implementações na página do Centro de
Implantação.
Oleodutos Azure Repos + Azure
3. Selecione O Azure Repos como fornecedor de controlo de fontes na página do Centro de Implantação
e selecione Continuar .
4. Na página 'Fornecedor de Construção', selecione Pipelines Azure (Pré-visualização) , e, em

seguida, selecione Continuar .
5. Na página Configure, na secção Código, selecione a Organização, Repositório e Ramo que pretende
implementar continuamente e selecionar Continuar .
NOTE
Se a sua organização Azure DevOps existente não estiver listada, poderá ter de ligá-la à sua subscrição Azure. Para
mais informações, consulte Defina o seu pipelinede lançamento de CD .
Na secção Build, especifique a Organização Azure DevOps, Projeto, enquadramento linguístico que os
Oleodutos Azure devem usar para executar tarefas de construção e, em seguida, selecionar Continuar .

7. Novos compromissos no repositório e sucursal selecionados agora implantam-se continuamente no seu

Serviço de Aplicações. Pode rastrear os compromissos e implementações na página do Centro de
Implantação.
Desativar a implementação contínua
Para desativar a implementação contínua, selecione Disconnect na parte superior da página do Centro de
Implementação da sua aplicação.

forma imprevisível durante a implementação, porque nem todos os ficheiros atualizados ao mesmo tempo. Isto
é indesejável para uma aplicação virada para o cliente. Existem algumas maneiras diferentes de evitar estas
questões:
Use repos não apoiados

Para aplicações Windows, pode configurar manualmente a implementação contínua a partir de um rescrito git
ou mercurial que o portal não suporta diretamente, como o GitLab. Faça-o escolhendo a caixa Externa na página
do Centro de Implantação. Para mais informações, consulte A instalação contínua de implantação utilizando
passos manuais.
Recursos adicionais
Investigar questões comuns com implantação contínua
Utilizar o Azure PowerShell
Documentação git
Kudu do projeto
Implantação local de Git para o Serviço de
Aplicações Azure
Este guia de como fazer mostra como implementar a sua aplicação para o Azure App Service a partir de um
repositório Git no seu computador local.
Pré-requisitos
Para seguir os passos neste guia:
Instale Git.
Tenha um repositório git local com código que queira implementar. Para descarregar um repositório de
amostras, faça o seguinte comando na janela do terminal local:
git clone https://github.com/Azure-Samples/nodejs-docs-hello-world.git
Prepare o seu repositório

Para obter construções automáticas do servidor de construção de Software de Aplicações Azure Kudu,
certifique-se de que a sua raiz de repositório tem os ficheiros corretos no seu projeto.
RUN T IM E F IC H EIRO S DE DIRETÓ RIO DE RA IZ
ASP.NET (apenas janelas) *.sln, *.csproj, ou padrão.aspx
Núcleo de ASP.NET *.sln ou *.csproj
PHP index.php
Rubi (apenas Linux) Gemfile
Node.js server.js, app.js, ou package.json com um script inicial
Python .py, requirements.txt, or runtime.txt _ *
HTML default.htm, default.html, default.asp, index.htm, index.html,

or iisstart.htm
Trabalhos Web <job_name>/correr.>< de extensão em dados de

_aplicações/empregos/contínuos para WebJobs contínuos,
ou Dados de Aplicações/empregos/desencadeados_ para
WebJobs desencadeados. Para mais informações, consulte a
documentação do Kudu WebJobs.
Funções Ver implantação contínua para funções Azure.

Para personalizar a sua implementação, inclua um ficheiro .deployment na raiz do repositório. Para mais
informações, consulte personalizar implementações e script de implementação personalizado.
NOTE
Se desenvolver no Visual Studio, deixe o Visual Studio criar um repositório para si. O projeto está imediatamente pronto
para ser implementado usando Git.

O Azure aloja o Azure Cloud Shell, um ambiente de shell interativo que pode utilizar através do seu browser.
Pode utilizar o Bash ou o PowerShell com o Cloud Shell para trabalhar com os serviços do Azure. Pode utilizar
os comandos pré-instalados do Cloud Shell para executar o código neste artigo sem ter de instalar nada no
ambiente local.

Aceda a https://shell.azure.com ou selecione o botão

Iniciar Cloud Shell para abrir o Cloud Shell no browser.
Selecione o botão Cloud Shell na barra de menus, na

parte direita do portal do Azure.

Implementar com o servidor de construção Kudu

A forma mais fácil de permitir a implementação local de Git para a sua aplicação com o servidor de
construção kudu App Service é utilizar o Azure Cloud Shell.
FtP e Git local podem implantar-se numa aplicação web Azure utilizando um utilizador de implementação.
Assim que configurar o utilizador de implementação, pode utilizá-lo para todas as suas implementações
Azure. O seu nome de utilizador de implementação de nível de conta e palavra-passe são diferentes das
credenciais de subscrição do Azure.
Para configurar o utilizador de implementação, execute o comando de conjunto de utilizadores de
implementação de webapp az em Azure Cloud Shell. Substitua <o <nome de utilizador> e a palavra-passe>
por um nome de utilizador e palavra-passe de implementação.
'@'.
A palavra-passe deve ter pelo menos oito caracteres de comprimento, com dois dos seguintes três
elementos: letras, números e símbolos.
A saída JSON mostra null a palavra-passe como . Se obtiver o erro 'Conflict'. Details: 409 , altere o nome
de utilizador. Se obtiver o 'Bad Request'. Details: 400 erro, utilize uma palavra-passe mais forte.
Obtenha o URL de implementação
Para obter o URL para permitir a implementação az webapp deployment source config-local-git local de Git
para uma aplicação existente, executar na Cloud Shell. Substitua <o nome <da aplicação> e o nome de
grupo> pelos nomes da sua aplicação e do seu grupo de recursos Azure.
az webapp deployment source config-local-git --name <app-name> --resource-group <group-name>
NOTE
Se estiver a utilizar um plano de serviço de aplicações linux, tem de adicionar este parâmetro: --pitão de execução;3.7
Ou, para criar uma nova aplicação az webapp create ativada por Git, executada na Cloud Shell com o
--deployment-local-git parâmetro. Substitua <> de <nome de aplicativo,> de nome de grupo e <> de nome
de plano com os nomes da sua nova app Git, do seu grupo de recursos Azure e do seu plano de Serviço de
Aplicações Azure.
az webapp create --name <app-name> --resource-group <group-name> --plan <plan-name> --deployment-local-git
Qualquer comando devolve um

https://<deployment-username>@<app-name>.scm.azurewebsites.net/<app-name>.git URL como: . Utilize este URL
para implementar a sua aplicação no próximo passo.
Em vez de utilizar este URL de nível de conta, também pode ativar o Git local utilizando credenciais de nível de
aplicações. O Azure App Service gera automaticamente estas credenciais para cada aplicação.
Obtenha as credenciais da aplicação executando o seguinte comando na Cloud Shell. Substitua <> de <nome
de aplicativo e> de nome de grupo com o nome da sua aplicação e o nome do grupo de recursos Azure.
az webapp deployment list-publishing-credentials --name <app-name> --resource-group <group-name> --query

scmUri --output tsv
Utilize o URL que regressa para implementar a sua aplicação no próximo passo.
Implementar a aplicação web
1. Abra uma janela terminal local para o seu repositório git local e adicione um telecomando Azure. No
comando seguinte, <substitua o url> pelo URL específico do utilizador de implementação ou URL
específico da aplicação que obteve do passo anterior.
git remote add azure <url>

2. Empurre para o git push azure master comando Azure com .
3. Na janela Git Credential Manager, introduza a sua palavra-passede utilizador de implementação , e
não a sua senha de entrada do Azure.
4. Reveja a saída. Você pode ver automatização específica de tempo de npm install execução, como
MSBuild para ASP.NET, para Node.js, e pip install para Python.
5. Navegue na sua aplicação no portal Azure para verificar se o conteúdo está implementado.
Implantação com pipelines Azure constrói

Se a sua conta tiver as permissões necessárias, pode configurar o Azure Pipelines (Preview) para permitir a
implementação local da Git para a sua aplicação.
A sua conta Azure deve ter permissões para escrever ao Azure Ative Directory e criar um serviço.
A sua conta Azure deve ter o papel de Proprietário na sua subscrição Azure.
Deve ser administrador no projeto Azure DevOps que pretende utilizar.
Para permitir a implementação local da Git para a sua aplicação com Pipelines Azure (Pré-visualização):
1. No portal Azure,procure e selecione Serviços de Aplicações.
2. Selecione a sua aplicação Azure App Service e selecione Deployment Center no menu esquerdo.
3. Na página do Centro de Implantação, selecione Git Local , e, em seguida, selecione Continuar .
4. Na página do fornecedor Build, selecione Pipelines Azure (Pré-visualização) , e, em seguida,

selecione Continuar .
5. Na página Configure, configure uma nova organização Azure DevOps, ou especifique uma
organização existente, e, em seguida, selecione Continuar .
NOTE
Se a sua organização Azure DevOps existente não estiver listada, poderá ter de ligá-la à sua subscrição Azure.
Para mais informações, consulte Defina o seu pipelinede lançamento de CD .
6. Dependendo do seu nívelde preços do plano de app service, pode ver uma página de
implementação. Escolha se ativa as ranhurasde implementação e, em seguida, selecione Continue .
7. Na página Resumo, reveja as definições e, em seguida, selecione Terminar .
8. Quando o Gasoduto Azure estiver pronto, copie o URL de repositório Git da página do Centro de
Implantação para utilizar no próximo passo.
9. Na janela do terminal local, adicione um telecomando Azure ao seu repositório git local. No comando,
<substitua a url> com o URL do repositório Git que obteve do passo anterior.
git remote add azure <url>
10. Empurre para o git push azure master comando Azure com .
11. Na página git Credential Manager, inscreva-se com o seu nome de utilizador visualstudio.com. Para
outros métodos de autenticação, consulte a visão geral da autenticação dos Serviços Azure DevOps.
12. Uma vez terminada a implantação, veja o progresso da construção em
, e o progresso da implantação
https://<azure_devops_account>.visualstudio.com/<project_name>/_build
em https://<azure_devops_account>.visualstudio.com/<project_name>/_release .
13. Navegue na sua aplicação no portal Azure para verificar se o conteúdo está implementado.

forma imprevisível durante a implementação, porque nem todos os ficheiros atualizados ao mesmo tempo.
Isto é indesejável para uma aplicação virada para o cliente. Existem algumas maneiras diferentes de evitar
estas questões:
Implantação de problemas
Pode ver as seguintes mensagens de erro comuns quando utilizar o Git para publicar numa aplicação do App
Service em Azure:
M EN SA GEM C A USA RESO L UÇ Ã O
Unable to access '[siteURL]': A aplicação não está a funcionar. Inicie a aplicação no portal Azure. A
Failed to connect to implementação da Git não está
[scmAddress]
disponível quando a aplicação web é
interrompida.
Couldn't resolve host A informação de endereço para o Utilize git remote -v o comando
'hostname' telecomando 'azul' está incorreta. para listar todos os telecomandos,
juntamente com o URL associado.
Verifique se o URL para o
telecomando 'azul' está correto. Se
necessário, remova e recrie este
controlo remoto utilizando o URL
correto.
No refs in common and none Não especificou uma git push Volte git push a correr,
specified; doing nothing. sucursal durante, ou push.default especificando
Perhaps you should specify a
branch such as 'master'. não .gitconfig definiu o valor em . git push azure master o ramo
principal: .
src refspec [branchname] does Tentaste empurrar para um ramo que Volte git push a correr,
not match any. não seja o mestre no controlo remoto especificando
azul. git push azure master o ramo
principal: .
RPC failed; result=22, HTTP Este erro pode acontecer se tentar Mude a configuração git na
code = 5xx. empurrar um repositório de git postBuffer máquina local para fazer
grande sobre HTTPS. o maior. Por exemplo:
git config --global
http.postBuffer 524288000
.
Error - Changes committed to Implementou uma aplicação Node.js Reveja npm ERR! as mensagens de
remote repository but your web com um ficheiro package.json que erro antes deste erro para obter mais
app not updated.
especifica módulos adicionais contexto sobre a falha. Seguem-se as
necessários. causas conhecidas npm ERR! deste
erro e as mensagens correspondentes:
Ficheiro pacote.json mal

formado:
npm ERR! Couldn't read
dependencies.
O módulo nativo não tem uma

distribuição binária para o
Windows:
npm ERR! \cmd "/c" "node-gyp
rebuild"\ failed with 1
ou
npm ERR! [modulename@version]
preinstall: \make || gmake\
Recursos adicionais
Documentação do Projeto Kudu
Implantação contínua para o Serviço de Aplicações Azure
Amostra: Criar uma aplicação web e implementar código a partir de um repositório git local (Azure CLI)
Amostra: Criar uma aplicação web e implementar código a partir de um repositório git local (PowerShell)
Implementar para o Serviço de Aplicações usando
ações do GitHub
GitHub Actions dá-lhe a flexibilidade para construir um fluxo de trabalho de ciclo de vida de desenvolvimento de
software automatizado. Com as Ações de Serviço de Aplicações Azure para GitHub, pode automatizar o seu fluxo
de trabalho para implantar no Azure App Service utilizando ações do GitHub.
IMPORTANT
GitHub Actions está atualmente em versão beta. Primeiro tem de se inscrever para se juntar à pré-visualização utilizando a
sua conta GitHub.
Um fluxo de trabalho é definido por um ficheiro YAML (.yml) no caminho do /.github/workflows/ seu repositório.
Esta definição contém os vários passos e parâmetros que compõem o fluxo de trabalho.
Para um fluxo de trabalho do Azure App Service, o ficheiro tem três secções:
SEC T IO N TA REFA S
Autenticação 1. Definir um chefe de serviço

2. Criar um segredo do GitHub
Compilação 1. Configurar o ambiente

2. Construir a aplicação web
Implementar 1. Implementar a aplicação web
Criar um principal de serviço

Pode criar um principal de serviço utilizando o comando ad sp create-for-rbac no Azure CLI. Pode executar este
comando utilizando a Azure Cloud Shell no portal Azure ou selecionando o botão Tentar.
az ad sp create-for-rbac --name "myApp" --role contributor --scopes /subscriptions/<subscription-

id>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name> --sdk-auth
Neste exemplo, substitua os espaços reservados no recurso pelo ID de subscrição, nome de grupo de recursos e
nome da aplicação. A saída são as credenciais de atribuição de funções que fornecem acesso à sua aplicação De
Serviço de Aplicações. Copie este objeto JSON, que pode utilizar para autenticar a partir do GitHub.
NOTE
Não precisa de criar um principal de serviço se decidir utilizar o perfil de publicação para autenticação.
IMPORTANT
É sempre uma boa prática conceder o mínimo acesso. É por isso que o âmbito do exemplo anterior está limitado à aplicação
específica do Serviço de Aplicações e não a todo o grupo de recursos.
Configure o segredo do GitHub

Também pode utilizar credenciais de nível de aplicação, ou seja, publicar o perfil para implementação. Siga os
passos para configurar o segredo:
1. Descarregue o perfil de publicação da aplicação Serviço de Aplicações a partir do portal utilizando a opção
de perfil Get Publish.
2. No GitHub,navegue no seu repositório, selecione Definições > Segredos > Adicionar um novo
segredo
3. Cole o conteúdo do ficheiro de perfil de publicação descarregado no campo de valor do segredo.

4. Agora no ficheiro de fluxo de trabalho no seu ramo: .github/workflows/workflow.yml substitua o segredo
pela entrada publish-profile da ação da App Web Azure.
- uses: azure/webapps-deploy@v2
with:
publish-profile: ${{ secrets.azureWebAppPublishProfile }}
5. Vê-se o segredo como mostrado abaixo uma vez definido.

Configurar o ambiente
A configuração do ambiente pode ser feita utilizando uma das ações de configuração.
L IN GUA GEM A Ç Ã O DE C O N F IGURA Ç Ã O
.NET actions/setup-dotnet
Java actions/setup-java
JavaScript actions/setup-node
Python actions/setup-python
Os exemplos a seguir mostram a parte do fluxo de trabalho que configura o ambiente para as várias línguas
apoiadas:
JavaScript
- name: Setup Node 10.x

uses: actions/setup-node@v1
with:
node-version: '10.x'
Python
- name: Setup Python 3.6

uses: actions/setup-python@v1
with:
python-version: 3.6
.NET
- name: Setup Dotnet 2.2.300

uses: actions/setup-dotnet@v1
with:
dotnet-version: '2.2.300'
Java
- name: Setup Java 1.8.x

uses: actions/setup-java@v1
with:
# If your pom.xml <maven.compiler.source> version is not in 1.8.x
# Please change the Java version to match the version in pom.xml <maven.compiler.source>
java-version: '1.8.x'
Construa a aplicação web

Isto depende do idioma e para as línguas suportadas pelo Azure App Service, esta secção deve ser os passos
padrão de construção de cada idioma.
Os exemplos a seguir mostram a parte do fluxo de trabalho que constrói a aplicação web, nos vários idiomas
suportados.
JavaScript
- name: 'Run npm'

shell: bash
run: |
# If your web app project is not located in your repository's root
# Please change your directory for npm in pushd
pushd .
npm install
npm run build --if-present
npm run test --if-present
popd
Python
- name: 'Run pip'

shell: bash
run: |
# Please change your directory for pip in pushd
pushd .
python -m pip install --upgrade pip
pip install -r requirements.txt --target=".python_packages/lib/python3.6/site-packages"
popd
.NET
- name: 'Run dotnet build'

shell: bash
run: |
# Please consider using pushd to change your path
pushd .
dotnet build --configuration Release --output ./output
popd
Java
- uses: actions/checkout@v1
- name: Set up JDK 1.8
uses: actions/setup-java@v1
with:
java-version: 1.8
- name: Build with Maven
run: mvn -B package --file pom.xml
Implementar no Serviço de Aplicações

Para implementar o seu código numa aplicação do Serviço de Aplicações, utilize a azure/webapps-deploy@v2 ação.
Esta ação tem quatro parâmetros:
PA RÂ M ET RO EXP L IC A Ç Ã O
nome de aplicativo (Obrigatório) Nome da app App Service
perfil de publicação (Opcional) Publique conteúdos de ficheiros de perfil com

segredos de implementação da Web
pacote (Opcional) Caminho para embalagem ou pasta. *.zip, *.war,

*.jar ou uma pasta para implantar
nome slot (Opcional) Introduza uma ranhura existente que não seja a
ranhura de produção
Implementar usando o perfil de publicação

Abaixo está o fluxo de trabalho da amostra para construir e implementar uma aplicação Node.js para a Azure
usando o perfil de publicação.
# File: .github/workflows/workflow.yml
on: push
jobs:
build-and-deploy:
steps:
# checkout the repo
- name: 'Checkout GitHub Action'
uses: actions/checkout@master

with:
- name: 'npm install, build, and test'
run: |
npm install
- name: 'Run Azure webapp deploy action using publish profile credentials'
uses: azure/webapps-deploy@v2
with:
app-name: node-rn
publish-profile: ${{ secrets.azureWebAppPublishProfile }}
Implementar usando o principal de serviço da Azure

Abaixo está o fluxo de trabalho da amostra para construir e implementar uma aplicação Node.js para Azure usando
um diretor de serviço Azure.
on: [push]
name: Node.js
jobs:
build-and-deploy:
steps:
# checkout the repo
- name: 'Checkout GitHub Action'
uses: actions/checkout@master
- uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}

with:
- name: 'npm install, build, and test'

run: |
npm install
# deploy web app using Azure credentials

- uses: azure/webapps-deploy@v2
with:
app-name: 'node-rn'
# Azure logout
- name: logout
run: |
az logout
Passos seguintes
Você pode encontrar o nosso conjunto de Ações agrupadas em diferentes repositórios no GitHub, cada um
contendo documentação e exemplos para ajudá-lo a usar GitHub para CI/CD e implementar suas aplicações para
Azure.
Fluxo de trabalho de ações para implantar para Azure
Início de sessão no Azure
Azure WebApp
Azure WebApp para contentores
Login/logout do Docker
Eventos que desencadeiam fluxos de trabalho
Implantação de K8s
Fluxos de trabalho de arranque
Fornecimento e implantação de microserviços
previsivelmente em Azure
Este tutorial mostra como fornecer e implementar uma aplicação composta por microserviços no Serviço de
Aplicações Azure como uma única unidade e de forma previsível usando modelos de grupo de recursos JSON e
scripts PowerShell.
Ao fornecer e implementar aplicações de alta escala compostas por microserviços altamente dissociados, a
repetível e a previsibilidade são cruciais para o sucesso. O Azure App Service permite-lhe criar microserviços que
incluam aplicações web, back ends móveis e aplicações API. O Azure Resource Manager permite-lhe gerir todos os
microserviços como uma unidade, juntamente com dependências de recursos, tais como bases de dados e
configurações de controlo de fontes. Agora, você também pode implementar tal aplicação usando modelos JSON
e scripts powerShell simples.
O que vai fazer

No tutorial, irá implementar uma aplicação que inclui:
Duas aplicações do App Service (ou é, dois microserviços)
Uma base de dados SQL de backend
Definições de aplicativos, cordas de ligação e controlo de fontes
Insights de aplicação, alertas, definições de autoscalcificação
Ferramentas que vai usar

Neste tutorial, utilizará as seguintes ferramentas. Como não é uma discussão abrangente sobre ferramentas, vou
manter-me no cenário de ponta a ponta e dar-vos uma breve introdução a cada um, e onde podem encontrar mais
informações sobre isso.
Modelos de Gestor de Recursos Azure (JSON )
Sempre que cria uma aplicação no Azure App Service, por exemplo, o Gestor de Recursos Azure usa um modelo
JSON para criar todo o grupo de recursos com os recursos componentes. Um modelo complexo do Azure
Marketplace pode incluir a base de dados, contas de armazenamento, o plano do Serviço de Aplicações, a própria
app, regras de alerta, definições de aplicações, configurações de escala automática e muito mais, e todos estes
modelos estão disponíveis para si através do PowerShell. Para obter mais informações sobre os modelos do
Gestor de Recursos Azure, consulte os modelos de gestor de recursos do Azure
Azure SDK 2.6 para Estúdio Visual
O mais recente SDK contém melhorias no suporte do modelo de Gestor de Recursos no editor da JSON. Você
pode usá-lo para criar rapidamente um modelo de grupo de recursos de raiz ou abrir um modelo JSON existente
(como um modelo de galeria descarregado) para modificação, povoar o arquivo de parâmetros e até mesmo
implementar o grupo de recursos diretamente a partir de uma solução do Grupo de Recursos Azure.
Para mais informações, consulte Azure SDK 2.6 para Visual Studio.
Azure PowerShell 0.8.0 ou mais tarde
A partir da versão 0.8.0, a instalação Azure PowerShell inclui o módulo Azure Resource Manager, além do módulo
Azure. Este novo módulo permite-lhe escrever a implantação de grupos de recursos.
Para mais informações, consulte A Utilização de PowerShell Azure com O Gestor de Recursos Azure
Explorador de Recursos do Azure
Esta ferramenta de pré-visualização permite-lhe explorar as definições JSON de todos os grupos de recursos na
sua subscrição e recursos individuais. Na ferramenta, pode editar as definições JSON de um recurso, eliminar toda
uma hierarquia de recursos e criar novos recursos. A informação prontamente disponível nesta ferramenta é muito
útil para a autoria do modelo porque mostra quais as propriedades que precisa definir para um determinado tipo
de recurso, os valores corretos, etc. Pode até criar o seu grupo de recursos no Portal Azure,depois inspecionar as
definições da JSON na ferramenta exploradora para o ajudar a templatizar o grupo de recursos.
Desdobrar para o botão Azure
Se utilizar o GitHub para controlo de fontes, pode colocar um botão Deploy para Azure na sua README. MD, que
permite uma chave de mão UI para Azure. Embora possa fazê-lo para qualquer aplicação simples, pode estender
isto para permitir a implementação de todo um grupo de recursos colocando um ficheiro azuredeploy.json na raiz
do repositório. Este ficheiro JSON, que contém o modelo de grupo de recursos, será utilizado pelo botão Deploy to
Azure para criar o grupo de recursos. Por exemplo, consulte a amostra do ToDoApp, que utilizará neste tutorial.
Obtenha o modelo de grupo de recursos da amostra

Então, agora vamos direto ao que isso.
1. Navegue para a amostra do Serviço de Aplicações ToDoApp.
2. Em readme.md, clique em Implementar para Azure .
3. Foi levado para o local de implantação para o azul e pediu para inserir parâmetros de implantação. Note
que a maioria dos campos estão povoados com o nome do repositório e algumas cordas aleatórias para si.
Pode alterar todos os campos se quiser, mas as únicas coisas que tem de introduzir são o login
administrativo do SQL Server e a palavra-passe, em seguida, clique em Next .
4. Em seguida, clique em Implementar para iniciar o processo de implementação. Uma vez que o processo
http://todoappse esgote, clique no link XXXX.azurewebsites.net para navegar na aplicação implementada.
O UI seria um pouco lento quando se navega pela primeira vez porque as aplicações estão apenas a
começar, mas convença-se de que é uma aplicação totalmente funcional.
5. De volta à página 'Enviar', clique no link Gerir para ver a nova aplicação no Portal Azure.
6. No dropdown Essentials, clique no link do grupo de recursos. Note também que a aplicação já está ligada
ao repositório GitHub no âmbito do Projeto Externo .
7. Na lâmina do grupo de recursos, note que já existem duas apps e uma Base de Dados SQL no grupo de
recursos.
Tudo o que viu em poucos minutos é uma aplicação de dois microserviços totalmente implantada, com todos os
componentes, dependências, configurações, base de dados e publicação contínua, criada por uma orquestração
automatizada no Azure Resource Manager. Tudo isto foi feito por duas coisas:
O botão Deploy para Azure
azuredeploy.json na raiz repo
Pode implementar esta mesma aplicação dezenas, centenas ou milhares de vezes e ter sempre a mesma
configuração. A repetível e a previsibilidade desta abordagem permitem-lhe implementar aplicações de alta escala
com facilidade e confiança.
Examinar (ou editar) AZUREDEPLOY. Rio JSON

Agora vamos ver como o repositório GitHub foi criado. Estará a utilizar o editor da JSON no Azure .NET SDK, por
isso, se ainda não tiver instalado o Azure .NET SDK 2.6,faça-o agora.
1. Clone o repositório ToDoApp utilizando a sua ferramenta git favorita. Na imagem abaixo, estou a fazer isto
no Team Explorer no Visual Studio 2013.
2. Da raiz do repositório, azuredeploy.json aberto no Estúdio Visual. Se não vir o painel de contorno jSON,
precisa de instalar o Azure .NET SDK.
Não vou descrever todos os detalhes do formato JSON, mas a secção Mais Recursos tem links para aprender a
linguagem do modelo do grupo de recursos. Aqui, vou mostrar-lhe as funcionalidades interessantes que podem
ajudá-lo a começar a fazer o seu próprio modelo personalizado para implementação de apps.
Parâmetros
Dê uma olhada na secção de parâmetros para ver se a maioria destes parâmetros são o que o botão Deploy to
Azure o leva a inserir. O local por trás do botão Deploy to Azure povoa o UI de entrada utilizando os parâmetros
definidos em azuredeploy.json. Estes parâmetros são utilizados ao longo das definições de recursos, tais como
nomes de recursos, valores de propriedade, etc.
Recursos
No nó de recursos, você pode ver que 4 recursos de alto nível são definidos, incluindo uma instância SQL Server,
um plano de Serviço de Aplicações e duas aplicações.
Plano do App Service
Vamos começar com um simples recurso de nível de raiz no JSON. No contorno jSON, clique no plano de serviço
de aplicações nomeado [hostingPlanName] para destacar o código JSON correspondente.
Note que type o elemento especifica a cadeia para um plano de Serviço de Aplicações (foi chamado de quinta de
servidores há muito, muito tempo), e outros elementos e propriedades são preenchidos usando os parâmetros
definidos no ficheiro JSON, e este recurso não tem recursos aninhados.
NOTE
Note também que apiVersion o valor do diz ao Azure com que versão da API REST utilizar a definição {} de recursos
JSON, e pode afetar a forma como o recurso deve ser formatado dentro da .
SQL Server
Em seguida, clique no recurso SQL Server chamado SQLSer ver no contorno JSON.
Note o seguinte sobre o código JSON realçado:
A utilização de parâmetros garante que os recursos criados são nomeados e configurados de uma forma
que os torna consistentes uns com os outros.
O recurso SQLServer tem dois recursos aninhados, cada um tem um valor diferente para type .
Os recursos aninhados no interior, “resources”: […] onde a dependsOn base de dados e as regras de
firewall são definidas, têm um elemento que especifica o ID de recurso do recurso SQLServer de nível raiz.
Isto diz ao Azure Resource Manager, "antes de criar este recurso, esse outro recurso já deve existir; e se esse
outro recurso for definido no modelo, então crie-o primeiro".
NOTE
Para obter informações detalhadas sobre como utilizar a resourceId() função, consulte funções de modelo de
gestor de recursos do Azure.
O efeito dependsOn do elemento é que o Gestor de Recursos Azure pode saber quais os recursos que
podem ser criados em paralelo e quais os recursos que devem ser criados sequencialmente.
Aplicação do Serviço de Aplicações
Agora, vamos passar para as próprias aplicações, que são mais complicadas. Clique na aplicação
[variáveis('apiSiteName')] no Contorno JSON para destacar o seu código JSON. Vais reparar que as coisas estão a
ficar muito mais interessantes. Para este fim, falarei sobre as características, uma a uma:
R e c u r so d e r a i z
A aplicação depende de dois recursos diferentes. Isto significa que o Gestor de Recursos Azure só criará a app
depois de criado o plano de Serviço de Aplicações e a instância do Servidor SQL.
D e fi n i ç õ e s d a a p l i c a ç ã o
As definições da aplicação também são definidas como um recurso aninhado.

No properties elemento config/appsettings para , tem duas definições de aplicação no formato
"<name>" : "<value>" .
PROJECT é um cenário KUDU que diz à implantação do Azure qual o projeto a utilizar numa solução de estúdio
visual multi-projeto. Mostrar-lhe-ei mais tarde como o controlo de fontes está configurado, mas como o código
ToDoApp está numa solução de estúdio visual multi-projeto, precisamos desta definição.
clientUrl é simplesmente uma definição de aplicação que o código de aplicação utiliza.
Cadei as de l i gaç ão
As cordas de ligação também são definidas como um recurso aninhado.
No properties elemento para , cada corda de ligação também é definida

config/connectionstrings
"<name>" : {"value": "…", "type": "…"} como um nome:par de valor, com o formato específico de . Para type o
elemento, MySql os SQLServer SQLAzure valores Custom possíveis são, e .
TIP
Para obter uma lista definitiva dos tipos de cordas de [ligação, execute o seguinte comando em Azure PowerShell:
Enum:GetNames ("Microsoft.WindowsAzure.Commands.Utilities.Websites.Services.WebEntities.DatabaseType")
C o n t r o l o d e c ó d i g o fo n t e
As definições de controlo de origem também são definidas como um recurso aninhado. O Azure Resource
Manager utiliza este recurso para configurar a publicação contínua (ver ressalva mais IsManualIntegration tarde)
e também para iniciar a implementação do código de aplicação automaticamente durante o processamento do
ficheiro JSON.
RepoUrl e branch deve ser bastante intuitivo e deve apontar para o repositório Git e o nome da sucursal para
publicar. Mais uma vez, estes são definidos por parâmetros de entrada.
Note no dependsOn elemento que, além do próprio sourcecontrols/web recurso da config/appsettings
config/connectionstrings aplicação, também depende e . Isto porque sourcecontrols/web uma vez configurado, o
processo de implementação do Azure tentará automaticamente implementar, construir e iniciar o código de
aplicação. Por isso, inserir esta dependência ajuda-o a certificar-se de que a aplicação tem acesso às definições de
aplicação e às cordas de ligação necessárias antes de o código de aplicação ser executado.
NOTE
Nota também IsManualIntegration que true está definido para . Esta propriedade é necessária neste tutorial porque
você realmente não é dono do repositório GitHub, e assim não pode realmente conceder permissão ao Azure para
configurar a publicação contínua do ToDoApp (isto é, impulsionar atualizações automáticas de repositório para Azure). Só
pode utilizar false o valor predefinido para o repositório especificado se tiver configurado as credenciais GitHub do
proprietário no portal Azure antes. Por outras palavras, se tiver configurado o controlo de origem para o GitHub ou
BitBucket para qualquer aplicação no Portal Azure anteriormente, utilizando as credenciais de utilizador, então o Azure
lembrar-se-á das credenciais e usá-las-á sempre que implementar qualquer aplicação do GitHub ou BitBucket no futuro. No
entanto, se ainda não o fez, a implementação do modelo JSON falhará quando o Gestor de Recursos do Azure tentar
configurar as definições de controlo de fonte da aplicação, porque não consegue entrar no GitHub ou bitBucket com as
credenciais do proprietário do repositório.
Compare o modelo JSON com o grupo de recursos implantados

Aqui, pode ver todas as lâminas da aplicação no Portal Azure, mas há outra ferramenta que é igualmente útil, se
não mais. Vá à ferramenta de pré-visualização do Azure Resource Explorer, que lhe dá uma representação JSON de
todos os grupos de recursos nas suas subscrições, uma vez que existem realmente no backend Azure. Você
também pode ver como a hierarquia JSON do grupo de recursos em Azure corresponde com a hierarquia no
ficheiro de modelo que é usado para criá-lo.
Por exemplo, quando vou à ferramenta do Azure Resource Explorer e expandi os nós do explorador, posso ver o
grupo de recursos e os recursos de nível raiz que são recolhidos sob os respetivos tipos de recursos.
Se perfurar uma aplicação, deverá ser capaz de ver detalhes de configuração da aplicação semelhantes ao
screenshot abaixo:
Mais uma vez, os recursos aninhados devem ter uma hierarquia muito semelhante às do seu ficheiro de modelo
JSON, e você deve ver as definições da aplicação, cordas de ligação, etc., devidamente refletidas no painel JSON. A
ausência de definições aqui pode indicar um problema com o seu ficheiro JSON e pode ajudá-lo a resolver o seu
ficheiro de modelo JSON.
Implante o modelo do grupo de recursos

O botão Deploy to Azure é ótimo, mas permite-lhe implementar o modelo de grupo de recursos em
azuredeploy.json apenas se já tiver empurrado azuredeploy.json para GitHub. O Azure .NET SDK também fornece
as ferramentas para que possa implementar qualquer ficheiro de modelo JSON diretamente da sua máquina local.
Para isso, siga os passos abaixo:
1. No Estúdio Visual, clique em File > New > Project .
2. Clique no Visual C# > Cloud > Azure Resource Group e, em seguida, clique em OK .
3. No modelo De Selecione Azure, selecione o modelo em branco e clique em OK .
4. Arraste azuredeploy.json para a pasta Modelo do seu novo projeto.
5. Do Solution Explorer, abra o azuredeploy.json copiado.

6. Só para o bem da demonstração, vamos adicionar alguns recursos padrão de Insight de aplicação ao nosso
ficheiro JSON, clicando em Adicionar Recurso . Se estiver apenas interessado em implementar o ficheiro
JSON, salte para os passos de implantação.
7. Selecione Insights de aplicação para aplicações web, em seguida, certifique-se de que um plano e app
de serviço de aplicação existentes é selecionado e, em seguida, clique em Adicionar .
Agora poderá ver vários novos recursos que, dependendo do recurso e do que faz, têm dependências do
plano de Serviço de Aplicações ou da app. Estes recursos não são ativados pela sua definição existente e tu
vais mudar isso.
8. No Contorno JSON, clique em appInsights AutoScale para destacar o seu código JSON. Este é o ajuste de
escala para o seu plano de Serviço de Aplicações.
9. No código JSON destacado, location localize as propriedades e enabled coloque-as como mostrado
abaixo.
10. No Contorno JSON, clique em CPUHigh appInsights para destacar o seu código JSON. Isto é um alerta.
11. Localize location isEnabled as propriedades e coloque-as como mostrado abaixo. Faça o mesmo com os
outros três alertas (lâmpadas roxas).
12. Está pronto para partir. Clique no direito do projeto e selecione Implementar > Nova Implementação .
13. Inicie sessão na sua conta Azure se ainda não o fez.
14. Selecione um grupo de recursos existente na sua subscrição ou crie um novo, selecione
azuredeploy.json e, em seguida, clique em Editar Parâmetros .
Agora poderá editar todos os parâmetros definidos no ficheiro do modelo numa mesa bonita. Os
parâmetros que definem os incumprimentos já terão os seus valores predefinidos, e os parâmetros que
definem uma lista de valores permitidos serão mostrados como downdowns.
15. Preencha todos os parâmetros vazios e utilize o endereço de repo GitHub para ToDoApp no repoUrl . Em
seguida, clique em Guardar .
NOTE
A autoscalcificação é uma funcionalidade oferecida no nível Standard ou superior, e os alertas de nível de plano são
funcionalidades oferecidas em nível Básico ou superior, terá de definir o parâmetro sku para Standard ou
Premium para ver todos os seus novos recursos app Insights iluminarem-se.
16. Clique em Implementar . Se selecionar Guardar palavras-passe, a palavra-passe será guardada no

ficheiro do parâmetro em texto simples . Caso contrário, será-lhe pedido que insera a palavra-passe da
base de dados durante o processo de implementação.
Já está! Agora basta ir ao Portal Azure e à ferramenta Azure Resource Explorer para ver os novos alertas e
configurações de escala automática adicionadas à sua aplicação implantada pela JSON.
Os seus passos nesta secção realizaram principalmente o seguinte:
1. Preparou o ficheiro do modelo
2. Criou um ficheiro de parâmetros para acompanhar o ficheiro do modelo
3. Implementou o ficheiro do modelo com o ficheiro parâmetro
O último passo é facilmente feito por um cmdlet PowerShell. Para ver o que o Visual Studio fez quando
implementou a sua aplicação, abra scripts\Deploy-AzureResourceGroup.ps1. Há lá muito código, mas vou destacar
todo o código pertinente que precisa para implementar o ficheiro do modelo com o ficheiro do parâmetro.
O último cmdlet, New-AzureResourceGroup é aquele que realmente realiza a ação. Tudo isto deve demonstrar-lhe
que, com a ajuda da ferramenta, é relativamente simples implementar a sua aplicação na nuvem previsivelmente.
Sempre que executar o cmdlet no mesmo modelo com o mesmo ficheiro de parâmetro, terá o mesmo resultado.
Resumo
Em DevOps, a repetível e a previsibilidade são chaves para qualquer implementação bem sucedida de uma
aplicação de alta escala composta por microserviços. Neste tutorial, implementou uma aplicação de dois
microserviços para o Azure como um único grupo de recursos utilizando o modelo do Gestor de Recursos Azure.
Esperemos que tenha lhe dado o conhecimento de que precisa para começar a converter a sua aplicação em Azure
num modelo e pode fortí-la e implantá-la previsivelmente.
Mais recursos
Linguagem do modelo do gestor de recursos azure
Autor de modelos de gestor de recursos azure
Funções de modelo de gestor de recursos azure
Implementar uma aplicação com o modelo de Gestor de Recursos Azure
Utilizar o Azure PowerShell com o Azure Resource Manager
Implantações de grupos de recursos de resolução de problemas em Azure
Passos seguintes
Para conhecer a sintaxe da JSON e propriedades para tipos de recursos implantados neste artigo, consulte:
Microsoft.Sql/servidores
Microsoft.Sql/servidores/bases de dados
Microsoft.Sql/servidores/firewallRules
Microsoft.Web/serverfarms
Microsoft.Web/sites
Microsoft.Web/sites/slots
Microsoft.Insights/autoscalesettings
Configure credenciais de implementação para o
O Azure App Service suporta dois tipos de credenciais para a implantação local de Git e implantação ftp/s. Estas
credenciais não são as mesmas que as suas credenciais de subscrição Azure.
Credenciais ao nível do utilizador : um conjunto de credenciais para toda a conta Azure. Pode ser
usado para implementar no App Service para qualquer aplicação, em qualquer subscrição, que a conta
Azure tenha permissão para aceder. É o conjunto padrão que é surgido no portal GUI (como a visão geral
e propriedades da página de recursosda app). Quando um utilizador tem acesso à aplicação através de
permissões de Controlo de Acesso Baseados em Funções (RBAC) ou de coadmino, esse utilizador pode
utilizar as suas próprias credenciais de nível de utilizador até que o acesso seja revogado. Não partilhe
estas credenciais com outros utilizadores do Azure.
Credenciais de nível de aplicações : um conjunto de credenciais para cada aplicação. Pode ser usado
para implantar apenas nessa aplicação. As credenciais para cada aplicação são geradas automaticamente
na criação de apps. Não podem ser configurados manualmente, mas podem ser reiniciados a qualquer
momento. Para que um utilizador tenha acesso a credenciais de nível de aplicações através de RBAC, esse
utilizador deve ser contribuinte ou superior na aplicação (incluindo a função incorporada do Colaborador
do Website). Os leitores não estão autorizados a publicar, e não podem aceder a essas credenciais.
Configure credenciais de nível de utilizador

Pode configurar as suas credenciais de nível de utilizador na página de recursosde qualquer aplicação .
Independentemente da aplicação que configura estas credenciais, aplica-se a todas as aplicações e a todas as
subscrições na sua conta Azure.
Na Nuvem Shell
Para configurar o utilizador de implementação na Cloud Shell,execute o comando de conjunto de utilizadores de
implementação de webapp az. Substitua < o nome de utilizador> e a < palavra-passe> por um nome de
'@'.
A saída JSON mostra a palavra-passe como null . Se obtiver o erro 'Conflict'. Details: 409 , altere o nome de
No portal
No portal Azure, deve ter pelo menos uma aplicação antes de poder aceder à página de credenciais de
implementação. Para configurar as suas credenciais de nível de utilizador:
1. No portal Azure, a partir do menu esquerdo, selecione Ser viços de Aplicação > ** < any_app>**
Centro de > Implantação > FTP > Dashboard .
Ou, se já configurar a implementação do Git, selecione App Ser vices > ** < any_app>** > Deployment
center > FTP/Credentials .
2. Selecione credenciais de utilizador, configure o nome do utilizador e a palavra-passe e, em seguida,

selecione 'Guardar Credenciais ' .
Depois de definir as suas credenciais de implementação, pode encontrar o nome de utilizador da implementação
git na página de visão geral da sua aplicação,
Se a implementação de Git estiver configurada, a página mostra um nome de utilizador Git/implementação;

caso contrário, um nome de utilizador FTP/implantação .
NOTE
O Azure não mostra a sua senha de implementação ao nível do utilizador. Se esquecer a palavra-passe, pode redefinir as
suas credenciais seguindo os passos nesta secção.
Utilize credenciais de nível de utilizador com FTP/FTPS

Autenticar para um ponto final FTP/FTPS utilizando credenciais de nível de utilizador requer um nome de
utilizador no seguinte formato: <app-name>\<user-name>
Uma vez que as credenciais de nível de utilizador estão ligadas ao utilizador e não a um recurso específico, o
nome de utilizador deve estar neste formato para direcionar a ação de início de sessão para o ponto final da
aplicação certa.
Obter e redefinir credenciais de nível de aplicações

Para obter as credenciais de nível de aplicações:
1. No portal Azure,a partir do menu esquerdo, selecione Ser viços de Aplicação > ** < any_app>** Centro
de > Implantação > FTP/Credenciais .
2. Selecione Credenciais de Aplicações e selecione o link Copy para copiar o nome de utilizador ou palavra-
passe.
Para redefinir as credenciais de nível de aplicação, selecione Reset Credenciais no mesmo diálogo.
Passos seguintes
Descubra como usar estas credenciais para implementar a sua aplicação a partir de Git local ou usando FTP/S.
Configurar ambientes de teste no Serviço de
Aplicações do Azure
Quando implementa a sua aplicação web, aplicação web no Linux, back back back móvel ou aplicação API
para o Azure App Service,pode utilizar uma ranhura de implementação separada em vez da ranhura de
produção padrão quando estiver a funcionar no nível de plano de plano standard , Premium ou Isolated
App Service. As ranhuras de implementação são aplicações ao vivo com os seus próprios nomes de
anfitriões. Os elementos de conteúdo e configuração da aplicação podem ser trocados entre duas ranhuras
de implementação, incluindo a ranhura de produção.
A implementação da sua aplicação para uma ranhura não produtiva tem os seguintes benefícios:
Pode validar as alterações de aplicações numa ranhura de implementação de encenação antes de trocá-
la com a ranhura de produção.
A implementação de uma aplicação para uma ranhura primeiro e a sua troca em produção certifica-se
de que todos os casos da ranhura são aquecidos antes de serem trocados em produção. Isto elimina o
tempo de inatividade quando implementa a sua aplicação. A reorientação do tráfego é perfeita, e
nenhum pedido é retirado por causa de operações de permuta. Pode automatizar todo este fluxo de
trabalho configurando a troca de automóveis quando não é necessária a validação pré-swap.
Depois de uma troca, a ranhura com aplicação previamente encenada tem agora a app de produção
anterior. Se as alterações trocadas na ranhura de produção não forem como espera, pode realizar a
mesma troca imediatamente para recuperar o seu "último bom site conhecido".
Cada nível de plano de app service suporta um número diferente de slots de implementação. Não há
nenhuma taxa adicional para usar ranhuras de implantação. Para saber o número de slots dos suportes de
nível da sua aplicação, consulte os limitesdo Serviço de Aplicações .
Para escalar a sua aplicação para um nível diferente, certifique-se de que o nível de destino suporta o
número de slots que a sua aplicação já utiliza. Por exemplo, se a sua aplicação tiver mais de cinco slots, não
pode escaloná-la para o nível Standard, porque o nível Standard suporta apenas cinco slots de
implementação.
Adicionar um bloco
A aplicação deve estar a funcionar no nível Standard , Premium ou Isolado para que possa ativar várias
ranhuras de implementação.
1. no portal Azure,procure e selecione Ser viços de Aplicações e selecione a sua aplicação.
2. No painel esquerdo, selecione ranhuras > de implantaçãoAdicione ranhuras .
NOTE
Se a aplicação ainda não estiver no nível Standard , Premium, ou Isolado, recebe uma mensagem que
indica os níveis suportados para permitir a publicação encenada. Neste ponto, tem a opção de selecionar
upgrade e ir ao separador Escala da sua aplicação antes de continuar.
3. Na caixa de diálogo Adicionar, dar um nome à ranhura e selecionar se clonar uma configuração de
aplicação a partir de outra ranhura de implementação. Selecione Adicionar para continuar.
Pode clonar uma configuração a partir de qualquer ranhura existente. As definições que podem ser
clonadas incluem definições de aplicativos, cordas de ligação, versões de enquadramento de idioma,
tomadas web, versão HTTP e bitness da plataforma.
4. Depois de adicionada a ranhura, selecione Feche para fechar a caixa de diálogo. A nova ranhura está
agora mostrada na página de ranhuras de implantação. Por predefinição, o tráfego % está
definido para 0 para a nova ranhura, com todo o tráfego do cliente encaminhado para a ranhura de
produção.
5. Selecione a nova ranhura de implementação para abrir a página de recursos da ranhura.
A slot de encenação tem uma página de gestão como qualquer outra app do App Service. Pode
alterar a configuração da ranhura. Para lembrá-lo que está a visualizar a ranhura de implementação,
o nome da aplicação é mostrado como ** <nome de aplicação>/<nome de slot>**, e o tipo de
aplicação é App Service (Slot) . Também pode ver a ranhura como uma aplicação separada no seu
grupo de recursos, com as mesmas designações.
6. Selecione o URL da aplicação na página de recursos da ranhura. A ranhura de implementação tem o
seu próprio nome de anfitrião e é também uma aplicação ao vivo. Para limitar o acesso do público à
ranhura de implantação, consulte as restrições IP do Serviço de Aplicações Azure.
A nova ranhura de implementação não tem conteúdo, mesmo que clone as definições de uma ranhura
diferente. Por exemplo, pode publicar nesta ranhura com Git. Você pode implantar para a ranhura a partir
de um ramo de repositório diferente ou de um repositório diferente.
O que acontece durante uma troca

Trocar etapas de operação
Quando troca duas ranhuras (geralmente de uma ranhura de preparação para a ranhura de produção), o
App Service faz o seguinte para garantir que a ranhura-alvo não experimenta tempo de inatividade:
1. Aplique as seguintes definições a partir da ranhura-alvo (por exemplo, a ranhura de produção) em
todas as instâncias da ranhura de origem:
Definições de aplicativos específicos para slot e cordas de ligação, se aplicável.
Definições de implantação contínuas, se ativadas.
Definições de autenticação do Serviço de Aplicações, se ativadas.
Qualquer um destes casos desencadeia todos os casos na ranhura de origem para reiniciar. Durante a
troca com pré-visualização,isto marca o fim da primeira fase. A operação de permuta é interrompida
e pode validar que a ranhura de origem funciona corretamente com as definições da ranhura do
alvo.
2. Aguarde por cada instância na ranhura de origem para completar o seu reinício. Se alguma instância
não reiniciar, a operação de permuta reverte todas as alterações à ranhura de origem e para a
operação.
3. Se a cache local estiver ativada, desencadeie a inicialização da cache local fazendo um pedido http
para a raiz de aplicação ("/") em cada instância da ranhura de origem. Aguarde até que cada instância
retorne qualquer resposta HTTP. A inicialização local do cache provoca um novo reinício em cada
instância.
4. Se a troca automática for ativada com aquecimento personalizado,desencadeie o início da aplicação
fazendo um pedido HTTP para a raiz de aplicação ("/") em cada instância da ranhura de origem.
Se applicationInitialization não for especificado, desencadeie um pedido HTTP para a raiz de
aplicação da ranhura de origem em cada instância.
Se uma instância devolver qualquer resposta HTTP, é considerado como aquecido.
5. Se todas as instâncias na ranhura de origem forem aquecidas com sucesso, troque as duas ranhuras
trocando as regras de encaminhamento para as duas ranhuras. Após este passo, a ranhura-alvo (por
exemplo, a ranhura de produção) tem a app que já foi aquecida na ranhura de origem.
6. Agora que a ranhura de origem tem a aplicação de pré-permuta anteriormente na ranhura-alvo,
execute a mesma operação aplicando todas as definições e reiniciando as instâncias.
Em qualquer ponto da operação de troca, todo o trabalho de inicialização das aplicações trocadas acontece
na ranhura de origem. A ranhura-alvo permanece on-line enquanto a ranhura de origem está a ser
preparada e aquecida, independentemente de onde a permuta tenha sucesso ou falhe. Para trocar uma
ranhura de preparação com a ranhura de produção, certifique-se de que a ranhura de produção é sempre a
ranhura-alvo. Desta forma, a operação de swap não afeta a sua aplicação de produção.
Que configurações são trocadas?
Quando se clona a configuração de outra ranhura de implantação, a configuração clonada é editável. Alguns
elementos de configuração seguem o conteúdo através de uma troca (não específica de ranhura), enquanto
outros elementos de configuração permanecem na mesma ranhura após uma troca (específica de ranhura).
As seguintes listas mostram as definições que mudam quando troca as ranhuras.
Definições trocadas:
Configurações gerais, tais como versão-quadro, tomadas web de 32/64 bits
Definições de aplicativos (pode ser configurada para ficar com uma ranhura)
Cordas de ligação (pode ser configurada para ficar colada a uma ranhura)
Mapeamentos de manipuladores
Certificados públicos
Conteúdo webJobs
Conexões híbridas *
Integração de rede virtual *
Pontos finais de serviço *
Rede de Entrega de Conteúdos Azure *
Estão previstas características marcadas com um asterisco (*) para serem destrocadas.
Definições que não são trocadas:
Pontos finais de publicação
Nomes de domínio personalizados
Certificados não públicos e definições TLS/SSL
Definições de escala
Programadores WebJobs
Restrições IP
Sempre ligado
Definições de diagnóstico
Partilha de recursos de origem cruzada (CORS)
NOTE
Algumas definições de aplicações que se aplicam a definições não trocadas também não são trocadas. Por exemplo,
uma vez que as definições WEBSITE_HTTPLOGGING_RETENTION_DAYS DIAGNOSTICS_AZUREBLOBRETENTIONDAYS de
diagnóstico não são trocadas, as configurações de aplicações relacionadas como e também não são trocadas, mesmo
que não apareçam como configurações de slot.
Para configurar uma definição de aplicação ou uma cadeia de ligação para se agarrar a uma ranhura
específica (não trocada), vá à página de Configuração para essa ranhura. Adicione ou edite uma definição
e, em seguida, selecione a definição de ranhura de implementação . A seleção desta caixa de verificação diz
ao Serviço de Aplicações que a definição não é permutável.
Troque duas ranhuras

Pode trocar slots de implementação na página de slots de implementação da sua aplicação e na página
'Over view'. Para obter detalhes técnicos sobre a troca de slot, consulte o que acontece durante a troca.
IMPORTANT
Antes de trocar uma aplicação de uma ranhura de implementação em produção, certifique-se de que a produção é o
seu slot alvo e que todas as configurações na ranhura de origem estão configuradas exatamente como você quer tê-
las em produção.
Para trocar as ranhuras de implantação:

1. Vá à página de ranhuras de implementação da sua aplicação e selecione Swap .
A caixa de diálogo Swap mostra as definições na fonte selecionada e as ranhuras de destino que
serão alteradas.
2. Selecione as ranhuras de Origem e Alvo desejadas. Normalmente, o alvo é a ranhura de produção.
Além disso, selecione os separadores de Alterações de Origem e Alterações de Destino e verifique
se as alterações de configuração são esperadas. Quando terminar, pode trocar imediatamente as
ranhuras selecionando Swap .
Para ver como o seu slot de destino funcionaria com as novas definições antes da troca realmente
acontecer, não selecione Swap , mas siga as instruções em Troca com pré-visualização.
3. Quando terminar, feche a caixa de diálogo selecionando Fechar .
Se tiver algum problema, consulte as trocas de Troubleshoot.
Troque com pré -visualização (troca de várias fases)
Antes de trocar em produção como o slot alvo, valide que a aplicação funciona com as definições trocadas.
A ranhura de origem também é aquecida antes da conclusão da permuta, o que é desejável para aplicações
críticas de missão.
Quando realiza uma troca com pré-visualização, o Serviço de Aplicações realiza a mesma operação de
swap, mas faz pausas após o primeiro passo. Em seguida, pode verificar o resultado da ranhura de
preparação antes de concluir a troca.
Se cancelar a troca, o Serviço de Aplicações reaplica elementos de configuração à ranhura de origem.
Para trocar com pré-visualização:
1. Siga os passos nas ranhuras de implementação swap, mas selecione Executar a troca com pré-
visualização .
A caixa de diálogo mostra-lhe como a configuração da ranhura de origem muda na fase 1 e como a
fonte e a ranhura do alvo mudam na fase 2.
2. Quando estiver pronto para iniciar a troca, selecione Iniciar a troca .
Quando a fase 1 terminar, é notificado na caixa de diálogo. Pré-visualizar a troca na
https://<app_name>-<source-slot-name>.azurewebsites.net ranhura de origem indo para .
3. Quando estiver pronto para completar o swap pendente, selecione 'Swap' completo na ação
Swap e selecione 'Swap Completo ' .
Para cancelar uma troca pendente, selecione Cancelar Trocar em vez disso.
4. Quando terminar, feche a caixa de diálogo selecionando Fechar .
Para automatizar uma troca de várias fases, consulte Automatizar com PowerShell.
Recue uma troca

Se ocorrerem erros na ranhura-alvo (por exemplo, na ranhura de produção) após uma troca de faixas
horárias, restaure as ranhuras para os seus estados de pré-swap trocando imediatamente as mesmas duas
ranhuras.
Configurar a troca automática

NOTE
A troca de automóveis não é suportada em aplicações web no Linux.
A troca de automóveis dinamiza cenários Azure DevOps onde pretende implementar a sua aplicação
continuamente com zero arranques a frio e zero tempo de inatividade para os clientes da app. Quando a
troca automática é ativada a partir de uma ranhura para a produção, sempre que empurra slot alterações de
código para essa ranhura, o Serviço de Aplicações troca automaticamente a app em produção depois de
aquecida na ranhura de origem.
NOTE
Antes de configurar a troca automática para a ranhura de produção, considere testar a troca automática numa
ranhura-alvo não produtiva.
Para configurar a troca automática:

1. Vá à página de recursos da sua aplicação. Selecione > ranhuras > <de origem desejadas> >
configurações gerais de configuração .
2. Para troca automática ativada, selecione On . Em seguida, selecione a ranhura de destino desejada
para a ranhura de implantação de swap supor automaticamente e selecione Guardar na barra de
comando.
3. Execute um impulso de código para a ranhura de origem. A troca de automóveis acontece após um
curto período de tempo e a atualização reflete-se no URL da sua ranhura-alvo.
Especificar aquecimento personalizado

Algumas aplicações podem exigir ações de aquecimento personalizadas antes da troca. O
applicationInitialization elemento de configuração em web.config permite especificar ações de
inicialização personalizadas. A operação de troca aguarda que este aquecimento personalizado termine
antes de trocar com a ranhura-alvo. Aqui está uma amostra web.config fragmento.
<system.webServer>
<applicationInitialization>
<add initializationPage="/" hostName="[app hostname]" />
<add initializationPage="/Home/About" hostName="[app hostname]" />
</applicationInitialization>
</system.webServer>
Para obter mais informações sobre a personalização do applicationInitialization elemento, consulte as

falhas mais comuns de troca de ranhuras de implantação e como corrigi-las.
Também pode personalizar o comportamento de aquecimento com uma ou ambas as seguintes definições
de aplicação:
WEBSITE_SWAP_WARMUP_PING_PATH : O caminho para o ping para aquecer o seu site. Adicione esta definição
de aplicação especificando um caminho personalizado que começa com um corte como o valor. Um
exemplo é /statuscheck . O valor predefinido é / .
WEBSITE_SWAP_WARMUP_PING_STATUSES : Códigos de resposta HTTP válidos para o funcionamento do
aquecimento. Adicione esta definição de aplicação com uma lista separada de códigos HTTP. Um exemplo
200,202 é. Se o código de estado devolvido não estiver na lista, as operações de aquecimento e troca
são interrompidas. Por predefinição, todos os códigos de resposta são válidos.
NOTE
O <applicationInitialization> elemento de configuração faz parte de cada start-up de cada aplicação,
enquanto as duas definições de aplicativos de comportamento de aquecimento aplicam-se apenas a swaps de slot.
Monitorize uma troca

Se a operação de swap demorar muito tempo a ser concluída, poderá obter informações sobre o
funcionamento do swap no registo de atividade.
Na página de recursos da sua aplicação no portal, no painel esquerdo, selecione registo de atividade .
Uma operação de troca aparece na Swap Web App Slots consulta de registo como . Pode expandi-lo e
selecionar uma das suboperações ou erros para ver os detalhes.
Tráfego de rota
Por padrão, todos os pedidos do cliente http://<app_name>.azurewebsites.net para o URL de produção da
aplicação são encaminhados para a ranhura de produção. Pode saquear uma parte do tráfego para outra
ranhura. Esta funcionalidade é útil se precisar de feedback do utilizador para uma nova atualização, mas não
está pronto para lançá-la para produção.
Tráfego de produção de rotas automaticamente
Para encaminhar automaticamente o tráfego de produção:
1. Vá à página de recursos da sua aplicação e selecione ranhuras de implementação .
2. Na coluna Tráfego % da ranhura que pretende encaminhar para, especificar uma percentagem
(entre 0 e 100) para representar a quantidade total de tráfego que pretende encaminhar. Selecione
Guardar .
Após a definição ser guardada, a percentagem especificada de clientes é aleatoriamente encaminhada para
a ranhura de não produção.
Depois de um cliente ser automaticamente encaminhado para uma vaga específica, é "fixado" para aquela
ranhura para a vida daquela sessão de cliente. No navegador cliente, pode ver qual a ranhura a que
x-ms-routing-name a sua sessão está fixada olhando para o cookie nos seus cabeçalhos HTTP. Um pedido
que é encaminhado para a ranhura de x-ms-routing-name=staging "encenação" tem o cookie. Um pedido que
é encaminhado para a ranhura x-ms-routing-name=self de produção tem o cookie.
NOTE
Junto ao portal Azure, também az webapp traffic-routing set pode utilizar o comando no Azure CLI para
definir as percentagens de encaminhamento de ferramentas CI/CD, como os gasodutos DevOps ou outros sistemas
de automação.
Tráfego de produção de rota manualmente

Além do encaminhamento automático de tráfego, o Serviço de Aplicações pode encaminhar pedidos para
uma ranhura específica. Isto é útil quando deseja que os seus utilizadores possam optar ou optar pela
aplicação beta. Para encaminhar manualmente o x-ms-routing-name tráfego de produção, utilize o
parâmetro de consulta.
Para que os utilizadores optem por não sair da sua aplicação beta, por exemplo, pode colocar este link na
sua página web:
<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>
A x-ms-routing-name=self corda especifica a ranhura de produção. Depois de o navegador cliente aceder ao

link, é redirecionado para a ranhura de produção. Cada pedido subsequente x-ms-routing-name=self tem o
cookie que coloca a sessão na ranhura de produção.
Para permitir que os utilizadores optem pela sua aplicação beta, defina o mesmo parâmetro de consulta
para o nome da ranhura de não produção. Segue-se um exemplo:
<webappname>.azurewebsites.net/?x-ms-routing-name=staging
Por padrão, são dadas novas ranhuras com uma regra de encaminhamento de 0% , mostrada em cinza.
Quando define explicitamente 0% este valor (mostrado em texto preto), os seus utilizadores
x-ms-routing-name podem aceder manualmente à ranhura de paragem utilizando o parâmetro de consulta.
Mas não serão encaminhados automaticamente para a ranhura porque a percentagem de encaminhamento
está definida para 0. Este é um cenário avançado onde pode "esconder" a sua ranhura de encenação do
público, permitindo que as equipas internas testem alterações na ranhura.
Apagar uma ranhura

Procure e selecione a sua aplicação. Selecione > *<ranhuras *de implantação para eliminar> > visão
geral . O tipo de aplicação é mostrado como App Ser vice (Slot) para lembrá-lo que está a ver uma
ranhura de implementação. Selecione Excluir na barra de comando.
Automatizar com o PowerShell

NOTE
AzureRM, que continuará a receber correções de erros até, pelo menos, dezembro de 2020. Para obter mais
informações sobre o novo módulo Az e a compatibilidade do AzureRM, veja Apresentação do novo módulo Az do
Azure PowerShell. Para obter instruções de instalação do módulo Az, veja Instalar o Azure PowerShell.
O Azure PowerShell é um módulo que fornece cmdlets para gerir o Azure através do Windows PowerShell,
incluindo suporte para gerir slots de implementação no Serviço de Aplicações Azure.
Para obter informações sobre a instalação e configuração do Azure PowerShell e sobre a autenticação do
Azure PowerShell com a sua subscrição Azure, consulte como instalar e configurar o Microsoft Azure
PowerShell.
New-AzWebApp -ResourceGroupName [resource group name] -Name [app name] -Location [location] -
AppServicePlan [app service plan name]
Criar uma ranhura
New-AzWebAppSlot -ResourceGroupName [resource group name] -Name [app name] -Slot [deployment slot name]
-AppServicePlan [app service plan name]
Iniciar uma troca com uma pré -visualização (permuta de várias fases) e aplicar a configuração da ranhura
de destino na ranhura de origem
$ParametersObject = @{targetSlot = "[slot name – e.g. "production"]"}

Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType
Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action applySlotConfig -Parameters
$ParametersObject -ApiVersion 2015-07-01
Cancelar uma permuta pendente (trocar com revisão ) e restaurar a configuração da ranhura de origem

Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action resetSlotConfig -ApiVersion
2015-07-01
Troca de blocos de implementação
$ParametersObject = @{targetSlot = "[slot name – e.g. "production"]"}

Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action slotsswap -Parameters
$ParametersObject -ApiVersion 2015-07-01
Monitorizar eventos de permuta no registo de atividade
Get-AzLog -ResourceGroup [resource group name] -StartTime 2018-03-07 -Caller SlotSwapJobProcessor
Apagar uma ranhura
Remove-AzResource -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots –

Name [app name]/[slot name] -ApiVersion 2015-07-01
Automatizar com modelos de Gestor de Recursos

Os modelos do Gestor de Recursos Azure são ficheiros JSON declarativos usados para automatizar a
implementação e configuração dos recursos Azure. Para trocar slots utilizando modelos de Gestor de
Recursos, irá definir duas propriedades nos recursos Microsoft.Web/sites/slots e recursos
microsoft.Web/sites:
buildVersion : trata-se de uma propriedade de cadeia que representa a versão atual da aplicação
implantada na ranhura. Por exemplo: "v1", "1.0.0.1", ou "2019-09-20T11:53:25.2887393-07:00".
targetBuildVersion : esta é uma propriedade buildVersion de cordas que especifica o que a ranhura
deve ter. Se o targetBuildVersion não buildVersion for igual à corrente, isto irá desencadear a operação
buildVersion de permuta encontrando a ranhura especificada .
Modelo de gestor de recursos de exemplo

O seguinte modelo de buildVersion Gestor de Recursos atualizará targetBuildVersion a ranhura de
preparação e definirá a ranhura de produção. Isto vai trocar as duas ranhuras. O modelo assume que já tem
um webapp criado com uma ranhura chamada "staging".
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"my_site_name": {
"defaultValue": "SwapAPIDemo",
"type": "String"
},
"sites_buildVersion": {
"defaultValue": "v1",
"type": "String"
}
},
"resources": [
{
"type": "Microsoft.Web/sites/slots",
"apiVersion": "2018-02-01",
"name": "[concat(parameters('my_site_name'), '/staging')]",
"location": "East US",
"kind": "app",
"properties": {
"buildVersion": "[parameters('sites_buildVersion')]"
}
},
{
"type": "Microsoft.Web/sites",
"apiVersion": "2018-02-01",
"name": "[parameters('my_site_name')]",
"location": "East US",
"kind": "app",
"dependsOn": [
"[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
],
"properties": {
"targetBuildVersion": "[parameters('sites_buildVersion')]"
}
}
]
}
Este modelo de Gestor de Recursos é idempotente, o que significa que pode ser executado repetidamente e
produzir o mesmo estado das ranhuras. Após a primeira targetBuildVersion execução, buildVersion
corresponderá à corrente, pelo que não será desencadeada uma troca.
Automatizar com o CLI

Para comandos Azure CLI para ranhuras de implantação, consulte a ranhura de implementação do webapp
az.
Trocas de resolução de problemas

Se ocorrer algum erro durante uma troca de slot,está registado em D:\home\LogFiles\eventlog.xml.
Também está registado no registo de erros específico da aplicação.
Aqui estão alguns erros comuns de troca:
Um pedido HTTP para a raiz de aplicação é cronometrado. A operação swap aguarda 90 segundos
por cada pedido http, e volta a tentar até 5 vezes. Se todas as tentativas forem cronometradas, a
operação de troca é interrompida.
A inicialização local do cache pode falhar quando o conteúdo da aplicação exceder a quota de disco
local especificada para a cache local. Para mais informações, consulte a visão geral do cache local.
Durante o aquecimento personalizado,os pedidos HTTP são feitos internamente (sem passar pelo
URL externo). Podem falhar com certas regras de reescrita de URL em Web.config. Por exemplo, as
regras para redirecionar nomes de domínio ou impor HTTPS podem impedir que os pedidos de
aquecimento cheguem ao código da aplicação. Para resolver este problema, modifique as suas regras
de reescrita adicionando as seguintes duas condições:
<conditions>
<add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
<add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
...
</conditions>
Sem um aquecimento personalizado, as regras de reescrita de URL ainda podem bloquear pedidos
HTTP. Para resolver este problema, modifique as suas regras de reescrita adicionando a seguinte
condição:
<conditions>
<add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
...
</conditions>
Algumas regras de restrição IP podem impedir que a operação de swap envie pedidos HTTP para a
sua aplicação. Os intervalos de endereços 10. 100. IPv4 que começam e são internos à sua
implantação. Deve permitir que se conectem à sua aplicação.
Após trocas de slot, a aplicação pode experimentar reiniciações inesperadas. Isto porque, após uma
troca, a configuração de ligação do nome de anfitrião fica dessincronizada, o que por si só não causa
reinícios. No entanto, certos eventos de armazenamento subjacentes (tais como falhas no volume de
armazenamento) podem detetar estas discrepâncias e forçar todos os processos dos trabalhadores a
reiniciar. Para minimizar este tipo de reinícios, defina a
WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 definição da aplicação em todas as ranhuras. No
entanto, esta definição de aplicações não funciona com aplicações da Windows Communication
Foundation (WCF).
Passos seguintes
Bloquear o acesso a faixas horárias não produtivas
Orientação sobre a implementação de aplicações
web utilizando modelos de Gestor de Recursos Azure
Este artigo fornece recomendações para a criação de modelos do Gestor de Recursos Azure para implementar
soluções do Serviço de Aplicações Azure. Estas recomendações podem ajudá-lo a evitar problemas comuns.
Definir dependências
Definir dependências para aplicações web requer uma compreensão de como os recursos dentro de uma aplicação
web interagem. Se especificar dependências numa ordem incorreta, poderá causar erros de implantação ou criar
uma condição de corrida que trave a implantação.
WARNING
Se incluir uma extensão do site MSDeploy no seu modelo, deve definir quaisquer recursos de configuração conforme
dependente do recurso MSDeploy. As alterações de configuração fazem com que o site reinicie assíncronamente. Ao tornar
os recursos de configuração dependentes do MSDeploy, certifique-se de que o MSDeploy termina antes do reinício do site.
Sem estas dependências, o site poderá reiniciar durante o processo de implementação do MSDeploy. Para um modelo de
exemplo, consulte o modelo WordPress com dependênciade implementação web .
A imagem seguinte mostra a ordem de dependência de vários recursos do Serviço de Aplicações:
Desdobre recursos na seguinte ordem:

Nível 1
Plano de Serviço de Aplicações.
Quaisquer outros recursos relacionados, como bases de dados ou contas de armazenamento.
Camada 2
A aplicação web depende do plano do Serviço de Aplicações.
A instância Azure Application Insights que visa a exploração do servidor depende do plano de Serviço de
Aplicações.
Nível 3
O controlo de fontes depende da aplicação web.
A extensão do site MSDeploy depende da aplicação web.
A instância Azure Application Insights que visa a aplicação web depende da aplicação web.
Nível 4
O certificado do Serviço de Aplicações-- depende do controlo de origem ou do MSDeploy se um dos dois
estiver presente. Caso contrário, depende da aplicação web.
Definições de configuração (strings de ligação, valores web.config, definições de aplicações) - depende do
controlo de origem ou do MSDeploy se um dos dois estiver presente. Caso contrário, depende da aplicação
web.
Nível 5
As encadernações do nome do anfitrião dependem do certificado se estiverem presentes. Caso contrário,
depende de um recurso de nível superior.
Extensões do site -- depende das definições de configuração se presentes. Caso contrário, depende de um
recurso de nível superior.
Normalmente, a sua solução inclui apenas alguns destes recursos e níveis. Para os níveis em falta, mapeie recursos
mais baixos para o nível mais próximo.
O exemplo que se segue mostra parte de um modelo. O valor da configuração da cadeia de ligação depende da
extensão MSDeploy. A extensão MSDeploy depende da aplicação web e da base de dados.
{
"name": "[parameters('appName')]",
"type": "Microsoft.Web/Sites",
...
"resources": [
{
"name": "MSDeploy",
"type": "Extensions",
"dependsOn": [
"[concat('Microsoft.Web/Sites/', parameters('appName'))]",
"[concat('Microsoft.Sql/servers/', parameters('dbServerName'), '/databases/',
parameters('dbName'))]",
],
...
},
{
"name": "connectionstrings",
"type": "config",
"dependsOn": [
"[concat('Microsoft.Web/Sites/', parameters('appName'), '/Extensions/MSDeploy')]"
],
...
}
]
}
Para uma amostra pronta a ser executada que utilize o código acima, consulte Modelo: Construa uma simples
Aplicação Web Umbraco.
Encontre informações sobre erros do MSDeploy

Se o seu modelo de Gestor de Recursos utilizar o MSDeploy, as mensagens de erro de implementação podem ser
difíceis de entender. Para obter mais informações após uma implementação falhada, tente os seguintes passos:
1. Vá à consola Kududo site.
2. Navegue na pasta em D:\home\LogFiles\SiteExtensions\MSDeploy.
3. Procure os ficheiros appManagerStatus.xml e appManagerLog.xml. O primeiro ficheiro regista o estado. O
segundo ficheiro regista informações sobre o erro. Se o erro não for claro para si, pode incluí-lo quando estiver
a pedir ajuda no fórum.
Escolha um nome único de aplicativo web

O nome da sua aplicação web deve ser globalmente único. Você pode usar uma convenção de nomeação que é
provável que seja única, ou você pode usar a função String única para ajudar a gerar um nome único.
{
"apiVersion": "2016-08-01",
"name": "[concat(parameters('siteNamePrefix'), uniqueString(resourceGroup().id))]",
...
}
Implementar certificado de aplicativo web a partir do Key Vault

NOTE
Este artigo foi atualizado para utilizar o novo módulo AZ do Azure PowerShell. Pode continuar a utilizar o módulo AzureRM,
que continuará a receber correções de erros até, pelo menos, dezembro de 2020. Para obter mais informações sobre o novo
módulo Az e a compatibilidade do AzureRM, veja Apresentação do novo módulo Az do Azure PowerShell. Para obter
instruções de instalação do módulo Az, veja Instalar o Azure PowerShell.
Se o seu modelo incluir um recurso Microsoft.Web/certificados para a ligação TLS/SSL, e o certificado estiver
armazenado num Cofre de Chaves, deve certificar-se de que a identidade do Serviço de Aplicações pode aceder ao
certificado.
No Azure global, o diretor de serviços de aplicações tem a identificação de abfa0a7c-a6b6-4736-8310-
5855508787cd . Para conceder acesso ao Key Vault para o diretor de serviço de aplicações, utilize:
Set-AzKeyVaultAccessPolicy `
-VaultName KEY_VAULT_NAME `
-ServicePrincipalName abfa0a7c-a6b6-4736-8310-5855508787cd `
-PermissionsToSecrets get `
-PermissionsToCertificates get
No Governo azure, o diretor de serviço seletiva tem a identificação de 6a02c803-dafd-4136-b4c3-

5a6f318b4714 . Utilize essa identificação no exemplo anterior.
No seu Cofre-Chave, selecione Cer tificados e Gera/Impor t para fazer o upload do certificado.
No seu modelo, forneça o nome keyVaultSecretName do certificado para o .
Para um modelo de exemplo, consulte a implementação de um certificado de aplicação web a partir do segredo
key vault e use-o para criar a ligação SSL.
Passos seguintes
Para um tutorial sobre a implementação de aplicações web com um modelo, consulte provision e implemente
microserviços previsivelmente em Azure.
Para conhecer a sintaxe jSON e propriedades para tipos de recursos em modelos, consulte a referência do
modelo do Gestor de Recursos Azure.
Buy a custom domain name for Azure App Service
(Comprar um nome de domínio personalizado para
o Serviço de Aplicações do Azure)
Os domínios do Serviço de Aplicações são domínios de alto nível que são geridos diretamente no Azure.
Facilitam a gestão de domínios personalizados para o Azure App Service. Este tutorial mostra-lhe como comprar
um domínio de Serviço de Aplicações e atribuir nomes de DNS ao Serviço de Aplicações Azure.
Para armazenamento Azure VM ou Azure, consulte o domínio de Serviço de Atribuição de Aplicações para O
Armazenamento Azure VM ou Azure. Para serviços de nuvem, consulte Configurar um nome de domínio
personalizado para um serviçode nuvem Azure .
Pré-requisitos
Crie uma aplicação do Serviço de Aplicações ou utilize uma aplicação que tenha criado para outro tutorial.
Remova o limite de gastos na sua subscrição. Não é possível comprar domínios do Serviço app com créditos
de subscrição gratuitos.
NOTE
Para utilizar domínios personalizados no Serviço de Aplicações Azure, o plano de Serviço de Aplicações da sua
aplicação deve ser um nível pago (Shared, Basic, Standard ou Premium). Neste passo, certifique-se de que a
aplicação está no nível de preços suportado.
Navegar para a aplicação no portal do Azure
No menu à esquerda, selecione Ser viços de Aplicações e selecione o nome da aplicação Web.
Será apresentada a página de gestão da aplicação do Serviço de Aplicações.
No painel de navegação esquerdo da página da aplicação, desloque-se para a secção Definições e selecione
O escalão atual da aplicação é realçado com um limite azul. Confirme que a aplicação não está no escalão F1 . O
DNS personalizado não é suportado no escalão F1 .
Se o plano de Serviço de Aplicações não estiver no nível F1, feche a página Scale up e salte para Comprar o
domínio.
Selecione qualquer uma das camadas não gratuitas (D1 , B1 , B2 , B3 ou qualquer camada na categoria
Produção ). Para obter opções adicionais, clique em Ver opções adicionais .
Clique em Aplicar .
Comprar o domínio
Informação sobre preços
Para obter informações sobre os domínios do serviço de aplicações do Azure, visite a página de preços do
serviço de aplicações e desloque-se até ao Domínio do Serviço de Aplicações.
Domínios de compra de lançamento
No separador Serviços de Aplicações, clique no nome da sua aplicação, selecione Definições e, em seguida,
selecione domínios Personalizados
Na página de domínios Personalizados, clique em Comprar Domínio .
NOTE
Se não conseguir ver a secção domínios do serviço de aplicações, tem de remover o limite de gastos na sua conta Azure
(ver Pré-requisitos).
Configure a compra de domínio

Na página de Domínio do Serviço de Aplicações, na caixa de Enter pesquisa de domínio, escreva o nome de
domínio que pretende comprar e digitar . Os domínios disponíveis sugeridos são mostrados logo abaixo da caixa
de texto. Selecione um ou mais domínios que pretende comprar.
NOTE
Os seguintes domínios de alto nível são suportados por domínios do Serviço de Aplicações: com, net, co.uk, org, nl , in, biz,
org.uk, e co.in. in
Clique nas Informações de Contacto e preencha o formulário de informação de contacto do domínio. Quando
terminar, clique em OK para voltar à página de Domínio do Serviço de Aplicações.
É importante que preencha todos os campos necessários com a maior precisão possível. Dados incorretos para
informações de contacto podem resultar na não compra de domínios.
Em seguida, selecione as opções desejadas para o seu domínio. Consulte a tabela seguinte para obter
explicações:
Proteção de privacidade Ativar Opte pela "Proteção da Privacidade",

que está incluída no preço de compra
gratuitamente. Alguns domínios de
alto nível são geridos por registradores
que não suportam a proteção da
privacidade, e estão listados na página
de proteção da Privacidade.
Atribuir nomes de anfitriões padrão www e**@** Selecione as encadernações de nome

de anfitrião desejadas, se desejar.
Quando a operação de compra de
domínio estiver concluída, a sua
aplicação pode ser acedida nos nomes
de anfitriões selecionados. Se a
aplicação estiver por trás do Azure
Traffic Manager,não vê a opção de
atribuir o domínio raiz (@), porque o
Gestor de Tráfego não suporta registos
A. Pode efazer alterações nas
atribuições de nome de anfitrião após a
compra do domínio estar concluída.
Aceitar termos e comprar

Clique em Termos Legais para rever os termos e encargos e, em seguida, clique em Comprar .
NOTE
Os domínios do serviço de aplicações usam o GoDaddy para o registo de domínioe o Azure DNS para acolher os domínios.
Além da taxa de registo de domínio, aplicam-se taxas de utilização para o DNS Azure. Para obter informações, consulte o
Preço do DNS Azure.
De volta à página de Domínio do Serviço de Aplicações, clique ok . Enquanto a operação está em curso, vê as
seguintes notificações:
Teste os nomes de anfitriões

Se atribuiu nomes de anfitriões padrão à sua aplicação, também vê uma notificação de sucesso para cada nome
de anfitrião selecionado.
Também vê os nomes de anfitriões selecionados na página de domínios Personalizados, na secção Nomes de

Anfitriões Personalizados.
NOTE
Uma etiqueta Não Segura para o seu domínio personalizado significa que ainda não está ligada a um certificado TLS/SSL,
e qualquer pedido HTTPS de um navegador para o seu domínio personalizado receberá um erro ou aviso, dependendo do
navegador. Para configurar a ligação TLS, consulte Proteja um nome DNS personalizado com uma ligação TLS/SSL no
Para testar os nomes de anfitriões, navegue para os nomes de anfitriões listados no navegador. No exemplo da
imagem anterior, tente navegar para kontoso.net e www.kontoso.net.
Atribuir nomes de anfitriões para app

Se optar por não atribuir um ou mais nomes de anfitriões predefinidos à sua aplicação durante o processo de
compra, ou se precisar de atribuir um nome de anfitrião não listado, pode atribuir um nome de anfitrião a
qualquer momento.
Também pode atribuir nomes de anfitriões no Domínio do Serviço de Aplicações a qualquer outra aplicação. Os
passos dependem se o Domínio do Serviço de Aplicações e a aplicação pertencem à mesma subscrição.
Subscrição diferente: Map estão os registos DNS personalizados do Domínio do Serviço de Aplicações para a
aplicação como um domínio comprado externamente. Para obter informações sobre a adição de nomes dNS
personalizados a um domínio de serviço de aplicações, consulte Gerir registos DNS personalizados. Para
mapear um domínio comprado externo para uma aplicação, consulte mapeie um nome DNS personalizado
existente para o Serviço de Aplicações Azure.
Mesma subscrição: Utilize os seguintes passos.
Lançamento adicionar nome de anfitrião
Na página de Serviços de Aplicações, selecione o nome da sua aplicação para a a sua designação de nomes de
anfitriões, selecione Definições e, em seguida, selecione domínios Personalizados .
Certifique-se de que o seu domínio adquirido está listado na secção domínios do serviço de aplicações, mas
não o selecione.
NOTE
Todos os Domínios do Serviço de Aplicações na mesma subscrição são mostrados na página de domínios
Personalizados da aplicação. Se o seu domínio estiver na subscrição da aplicação, mas não o consegue ver na página de
domínios Personalizados da aplicação, tente reabrir a página de domínios Personalizados ou atualizar a página web.
Verifique também o sino de notificação no topo do portal Azure para obter falhas de progresso ou criação.
Selecione Adicionar nome de anfitrião .

Configurar o nome de anfitrião
No diálogo Add hostname, escreva o nome de domínio totalmente qualificado do seu Domínio de Serviço de
Aplicações ou qualquer subdomínio. Por exemplo:
kontoso.net
www.kontoso.net
abc.kontoso.net
Quando terminar, selecione Validar . O tipo de registo de nome de anfitrião é automaticamente selecionado para
si.
Quando a operação estiver concluída, consulte uma notificação de sucesso para o nome de anfitrião atribuído.
Fechar adicionar nome de anfitrião

Na página Adicionar nome de anfitrião, atribua qualquer outro nome de anfitrião à sua aplicação, conforme
desejado. Quando terminar, feche a página Adicionar nome de anfitrião.
Deverá agora ver o nome de anfitrião recentemente atribuído na página de domínios Personalizados da sua
aplicação.
Teste os nomes de anfitriões
Navegue para os nomes de anfitriões listados no navegador. No exemplo da imagem anterior, tente navegar para
abc.kontoso.net.
Renovar o domínio
O domínio do Serviço de Aplicações que comprou é válido por um ano a partir do momento da compra. Por
predefinição, o domínio está configurado para renovar automaticamente, cobrando o seu método de pagamento
para o próximo ano. Pode renovar manualmente o seu nome de domínio.
Se quiser desativar a renovação automática, ou se quiser renovar manualmente o seu domínio, siga os passos
aqui.
No separador Serviços de Aplicações, clique no nome da sua aplicação, selecione Definições e, em seguida,
selecione domínios Personalizados .
Na secção Domínios do Ser viço de Aplicações, selecione o domínio que pretende configurar.
A partir da navegação esquerda do domínio, selecione renovação de domínio. Para parar de renovar
automaticamente o seu domínio, selecione Off , e, em seguida, Guardar .
Para renovar manualmente o seu domínio, selecione Renovar o domínio . No entanto, este botão só está ativo 90
dias antes da expiração do domínio.
Se a renovação do seu domínio for bem sucedida, receberá uma notificação por e-mail dentro de 24 horas.
Quando o domínio expirar

O Azure lida com domínios de Serviço de Aplicações expirados ou expirados da seguinte forma:
Se a renovação automática for desativada: 90 dias antes da expiração do domínio, é enviado um e-mail de
notificação de renovação para si e o botão de domínio Renovar é ativado no portal.
Se a renovação automática estiver ativada: No dia seguinte à data de validade do seu domínio, o Azure tenta
cobrar-lhe a renovação do nome de domínio.
Se ocorrer um erro durante a renovação automática (por exemplo, o seu cartão no ficheiro expira), ou se a
renovação automática for desativada e permitir que o domínio expire, o Azure notifica-o da expiração do
domínio e estaciona o seu nome de domínio. Pode renovar manualmente o seu domínio.
Nos dias 4 e 12 dias após a expiração, o Azure envia-lhe e-mails de notificação adicionais. Pode renovar
manualmente o seu domínio.
No 19º dia após a expiração, o seu domínio permanece em espera, mas fica sujeito a uma taxa de resgate.
Pode ligar para o apoio ao cliente para renovar o seu nome de domínio, sujeito a quaisquer taxas de
renovação e de resgate aplicáveis.
No 25º dia após a expiração, o Azure coloca o seu domínio em leilão com um serviço de leilões da indústria
de nome de domínio. Pode ligar para o apoio ao cliente para renovar o seu nome de domínio, sujeito a
quaisquer taxas de renovação e de resgate aplicáveis.
No 30º dia após a expiração, já não és capaz de redimir o teu domínio.
Gerir registos DNS personalizados

Em Azure, os registos DNS para um Domínio de Serviço de Aplicações são geridos utilizando O DNS Azure. Pode
adicionar, remover e atualizar os registos de DNS, tal como para um domínio comprado externamente.
Domínio de serviço de aplicativo aberto
No portal Azure, a partir do menu esquerdo, selecione Todos os domínios > de serviço de aplicação de todos
osser viços.
Selecione o domínio para gerir.

Zona DNS de acesso
No menu esquerdo do domínio, selecione a zona DNS .
Esta ação abre a página da zona DNS do seu Domínio de Serviço de Aplicações em DNS Azure. Para obter
informações sobre como editar registos DNS, consulte como gerir as Zonas DNS no portal Azure.
Cancelar compra (excluir domínio)

Depois de adquirir o Domínio do Serviço de Aplicações, tem cinco dias para cancelar a sua compra para um
reembolso total. Após cinco dias, pode eliminar o Domínio do Serviço de Aplicações, mas não pode receber um
reembolso.
Domínio de serviço de aplicativo aberto
No portal Azure, a partir do menu esquerdo, selecione Todos os domínios > de serviço de aplicação de todos
osser viços.
Selecione o domínio para que deseja cancelar ou eliminar.

Eliminar encadernações de nome de anfitrião
No menu esquerdo do domínio, selecione ligações hostname . As encadernações de nome de anfitrião de todos
os serviços azure estão listadas aqui.
Não é possível eliminar o Domínio do Serviço de Aplicações até que todas as ligações de nome de anfitrião
sejam eliminadas.
Elimine cada encadernação de nome de anfitrião selecionando... > Apagar . Depois de todas as ligações serem
eliminadas, selecione Guardar .
Cancelar ou excluir
No menu esquerdo do domínio, selecione Visão Geral .
Se o período de cancelamento no domínio adquirido não tiver decorrido, selecione Cancelar a compra . Caso
contrário, vê um botão Delete. Para eliminar o domínio sem reembolso, selecione Eliminar .
Para confirmar a operação, selecione Sim .

Após a operação estar concluída, o domínio é liberado a partir da sua subscrição e disponível para que qualquer
pessoa volte a comprar.
Direcionar o URL predefinido para um diretório personalizado

Por predefinição, o Serviço de Aplicações direciona os pedidos Web para o diretório de raiz do código da sua
aplicação. Para direcioná-los para public um subdiretório, como, consulte o Direct predefinição URL para um
diretório personalizado.
Configure um nome de domínio personalizado no
Serviço de Aplicações Azure com integração do
Gestor de Tráfego
NOTE
Para serviços de nuvem, consulte Configurar um nome de domínio personalizado para um serviçode nuvem Azure .
Quando utiliza o Gestor de Tráfego Azure para carregar o tráfego de equilíbrio para o Serviço de Aplicações
Azure,a aplicação do Serviço de Aplicações pode ser acedida utilizando o ** <ponto final do traffic-
manager>.trafficmanager.net**. Pode atribuir um nome de domínio.personalizado, como www contoso.com, com
a sua app App Service, de forma a fornecer um nome de domínio mais reconhecível para os seus utilizadores.
Este artigo mostra-lhe como configurar um nome de domínio personalizado com uma aplicação do App Service
que está integrada com o Traffic Manager.
NOTE
Apenas os registos CNAME são suportados quando configura um nome de domínio utilizando o ponto final do Gestor de
Tráfego. Como os registos A não são suportados, um mapeamento de domínio raiz, como contoso.com também não é
suportado.
Para mapear um nome DNS personalizado para uma aplicação integrada com o Azure Traffic Manager, o plano de
Serviço de Aplicações da aplicação web deve estar em nível Standard ou superior. Neste passo, vai confirmar que
a aplicação do Serviço de Aplicações está no escalão de preço suportado.
No portal Azure,procure e selecione Serviços de Aplicações.
Na navegação à esquerda da página da aplicação, selecione Scale up (plano de serviço de aplicações) .
O escalão atual da aplicação é realçado com um limite azul. Verifique se a aplicação está no nível Standard ou
superior (qualquer nível na categoria Produção ou Isolado). Se sim, feche a página Scale up e salte para Criar o
mapeamento CNAME.
Se precisar de aumentar a sua aplicação, selecione qualquer um dos níveis de preços na categoria Produção. Para
obter opções adicionais, clique em Ver opções adicionais .
Clique em Aplicar .
Criar ponto final do Gestor de Tráfego

Seguindo os passos em Add ou Delete Endpoints,adicione a sua aplicação app Service como um ponto final no
perfil do Gestor de Tráfego.
Uma vez que a sua aplicação App Service está num nível de preços suportado, aparece na lista de alvos
disponíveis do Serviço de Aplicações quando adiciona o ponto final. Se a sua aplicação não estiver listada,
verifique o nível de preços da sua aplicação.
Criar o mapeamento CNAME

NOTE
Para configurar um domínio do Serviço de Aplicações que adquiriu,ignore esta secção e vá para o domínio personalizado
Enable.
NOTE
Pode utilizar o Azure DNS para configurar um nome DNS personalizado para o Serviço de Aplicações Azure. Para obter mais
informações, veja Utilizar o DNS do Azure para oferecer definições de domínio personalizado para um serviço do Azure.

Localize a página para gerir os registos DNS. Cada fornecedor de domínio tem a sua própria interface de registos
DNS, por isso, consulte a documentação do fornecedor. Procure áreas do site com os nomes Nome de Domínio ,
DNS ou Gestão de Ser vidor de Nomes .
Em muitos casos, pode encontrar a página de registos DNS ao procurar uma ligação como Os meus domínios
nas informações da sua conta. Aceda a essa página e procure uma ligação que tenha um nome parecido com
Ficheiro de zona , Registos DNS ou Configuração avançada .
NOTE
Embora as especificidades de cada fornecedor de domínio variem, você mapeia de um nome de domínio
personalizado não raiz (como www.contoso.com ) para o nome de domínio do Gestor de Tráfego
(contoso.trafficmanager.net ) que está integrado com a sua app.
NOTE
Se um registo já estiver a ser utilizado e precisar de ligar preventivamente as suas aplicações ao mesmo, pode criar um
registo CNAME adicional. Por exemplo, para ligar preventivamente o contoso.com. à sua aplicação, crie um registo CNAME
a partir de awcheck .www para contoso.trafficmanager.net . Em seguida, pode.adicionar "www contoso.com" à sua
aplicação sem a necessidade de alterar o registo "www" CNAME. Para mais informações, consulte Migrate um nome DNS
ativo para o Serviço de Aplicações Azure.
Depois de ter terminado de adicionar ou modificar os registos de DNS no seu fornecedor de domínio, guarde as
alterações.
E os domínios de raiz?
Uma vez que o Traffic Manager apenas suporta o mapeamento de domínio personalizado com registos CNAME, e
porque os padrões DNS não suportam registos CNAME para mapear domínios radiculares (por exemplo,
contoso.com), o Traffic Manager não suporta o mapeamento para domínios radiculares. Para resolver este
problema, utilize um redirecionamento de URL a partir do nível da aplicação. Em ASP.NET Core, por exemplo, pode
utilizar a reescrita de URL. Em seguida, utilize o Gestor de Tráfego para carregar o equilíbrio do subdomínio
( www.contoso.com ).
Para cenários de alta disponibilidade, pode implementar uma configuração DNS tolerante a falhas sem Traffic
Manager, criando vários registos A que apontam do domínio raiz para o endereço IP de cada cópia da aplicação.
Em seguida, mapeie o mesmo domínio raiz para todas as cópias da aplicação. Uma vez que o mesmo nome de
domínio não pode ser mapeado para duas aplicações diferentes na mesma região, esta configuração só funciona
quando as cópias da sua aplicação estão em diferentes regiões.
Ativar domínio personalizado

Depois de se terem propagado os registos do seu nome de domínio, utilize o navegador para verificar se o seu
nome de domínio personalizado se resolve na sua aplicação App Service.
NOTE
Pode levar algum tempo para o seu CNAME propagar através do sistema DNS. Pode utilizar um serviço
https://www.digwebinterface.com/ de forma a verificar se o CNAME está disponível.
1. Uma vez que a resolução de domínio suceda, volte à sua página de aplicações no Portal Azure
2. A partir da navegação à esquerda, selecione Domínios Personalizados > Adicione nome de anfitrião .
3. Digite o nome de domínio personalizado que mapeou anteriormente e selecione Validar .
4. Certifique-se de que o tipo de registo do Nome anfitrião está definido para CNAME.(www
example.com ou qualquer subdomínio) .
5. Uma vez que a aplicação do Serviço de Aplicações está agora integrada com um ponto final do Traffic
Manager, deve ver o nome de domínio do Gestor de Tráfego sob a configuração CNAME . Selecione-o e
clique em Adicionar domínio personalizado .
Passos seguintes
Proteger um nome DNS personalizado com um enlace SSL no Serviço de Aplicações do Azure
Migrar um nome dNS ativo para o Serviço de
Aplicações Azure
Este artigo mostra-lhe como migrar um nome DNS ativo para o Azure App Service sem qualquer tempo de
inatividade.
Quando migra um site ao vivo e o seu nome de domínio DNS para o App Service, esse nome DNS já está a servir
tráfego ao vivo. Pode evitar o tempo de inatividade na resolução do DNS durante a migração, ligando
preventivamente o nome DNS ativo à sua app App Service.
Se não está preocupado com o tempo de inatividade na resolução do DNS, consulte mapeie um nome dNS
personalizado existente para o Serviço de Aplicações Azure.
Pré-requisitos
Para completar este how-to:
Certifique-se de que a sua aplicação App Service não está em nível FREE.
Ligue o nome de domínio preventivamente

Quando liga um domínio personalizado preventivamente, realiza ambos os seguintes antes de efazer quaisquer
alterações nos seus registos DNS:
Verificar a propriedade do domínio
Ativar o nome de domínio para a sua aplicação
Quando finalmente migrar o seu nome DNS personalizado do antigo site para a aplicação App Service, não
haverá tempo de inatividade na resolução do DNS.
NOTE
Pode utilizar o Azure DNS para configurar um nome DNS personalizado para o Serviço de Aplicações Azure. Para obter mais
informações, veja Utilizar o DNS do Azure para oferecer definições de domínio personalizado para um serviço do Azure.

Localize a página para gerir os registos DNS. Cada fornecedor de domínio tem a sua própria interface de registos
DNS, por isso, consulte a documentação do fornecedor. Procure áreas do site com os nomes Nome de Domínio ,
DNS ou Gestão de Ser vidor de Nomes .
Em muitos casos, pode encontrar a página de registos DNS ao procurar uma ligação como Os meus domínios
nas informações da sua conta. Aceda a essa página e procure uma ligação que tenha um nome parecido com
Ficheiro de zona , Registos DNS ou Configuração avançada .
NOTE
Criar registo de verificação de domínio

Para verificar a propriedade do domínio, adicione um registo TXT. Os mapas de registo tXT de awcheck.<
subdomínio> para _ <o nome de aplicação>.azurewebsites.net_.
O registo do TXT de que precisas depende do registo do DNS que queres migrar. Por exemplo, consulte a @ tabela
seguinte (normalmente representa o domínio raiz):
EXEM P LO DE REGISTO DN S H O SP EDEIRO T XT VA LO R T XT
@(raiz) awverificar <nome de

aplicação>.azurewebsites.net
www (sub) awcheck.www <nome de

*(wildcard) awcheck.* <nome de

Na sua página de registos dNS, note o tipo de registo do nome DNS que pretende migrar. O Serviço de Aplicações
suporta mapeamentos de registos CNAME e A.
NOTE
Para certos fornecedores, como awverify.* o CloudFlare, não é um registo válido. Use * apenas em vez disso.
NOTE
Os * registos wildcard não validarão subdomínios com um registo cname existente. Pode ser necessário criar
explicitamente um disco TXT para cada subdomínio.
Ativar o domínio para a sua aplicação

No portal Azure,na navegação à esquerda da página da aplicação, selecione domínios Personalizados.
Na página de domínios Personalizados, selecione o + ícone ao lado de Adicionar nome de anfitrião .
Digite o nome de domínio totalmente qualificado para o www.contoso.com que adicionou o registo TXT, como . Para
um domínio *wildcard (como .contoso.com), pode utilizar qualquer nome DNS que corresponda ao domínio
wildcard.
Selecione Validar .
O botão Adicionar nome de anfitrião é ativado.
Certifique-se de que o tipo de registo hostname está definido para o tipo de registo DNS que pretende migrar.
Poderá demorar algum tempo até que o nome de anfitrião novo seja refletido na página Domínios
personalizados da aplicação. Experimente atualizar o browser para atualizar os dados.
O seu nome DNS personalizado está agora ativado na sua aplicação Azure.
Remapear o nome DNS ativo

A única coisa que resta fazer é remapear o seu registo dNS ativo para apontar para o Serviço de Aplicações. Neste
momento, ainda aponta para o seu antigo site.
Copiar o endereço IP da aplicação (apenas um registo )
Se estiver a mapear um disco CNAME, ignore esta secção.
Para remapear um registo A, precisa do endereço IP externo da aplicação app Service, que é mostrado na página
de domínios Personalizados.
Feche a página Add hostname selecionando X no canto superior direito.
Na página Domínios personalizados , copie o endereço IP da aplicação.
Atualizar o registo dNS

De volta à página de registos dNS do seu fornecedor de domínio, selecione o registo DNS para remapear.
Para contoso.com o exemplo do domínio radicular, remape o registo A ou CNAME como os exemplos na tabela a
seguir:
EXEM P LO F Q DN T IP O DE REGISTO A N F IT RIÃ O VA LO R
contoso.com (raiz) A @ Endereço IP de Copiar o

endereço IP da aplicação
EXEM P LO F Q DN T IP O DE REGISTO A N F IT RIÃ O VA LO R
www.contoso.com (sub) CNAME www <nome de

*.contoso.com (wildcard) CNAME * <nome de

Guarde as suas definições.

As consultas de DNS devem começar a resolver a sua aplicação de Serviço de Aplicações imediatamente após a
propagação do DNS.
Domínio ativo em Azure

Pode migrar um domínio personalizado ativo em Azure, entre subscrições ou dentro da mesma subscrição. No
entanto, tal migração sem tempo de inatividade requer a aplicação de origem e a aplicação alvo é atribuída ao
mesmo domínio personalizado em determinado momento. Por isso, é necessário certificar-se de que as duas
aplicações não são implantadas na mesma unidade de implementação (internamente conhecida como webspace).
Um nome de domínio pode ser atribuído a apenas uma aplicação em cada unidade de implementação.
Pode encontrar a unidade de implantação da sua aplicação olhando
<deployment-unit>.ftp.azurewebsites.windows.net para o nome de domínio do URL FTP/S . Verifique e certifique-se
de que a unidade de implementação é diferente entre a aplicação de origem e a aplicação alvo. A unidade de
implementação de uma aplicação é determinada pelo plano de Serviço de Aplicações em que se encontra. É
selecionado aleatoriamente pelo Azure quando crias o plano e não podes ser alterado. O Azure apenas garante
que dois planos estão na mesma unidade de implantação quando os cria no mesmo grupo de recursos e na
mesma região, mas não tem qualquer lógica para garantir que os planos estão em diferentes unidades de
implantação. A única maneira de criar um plano numa unidade de implantação diferente é continuar a criar um
plano num novo grupo de recursos ou região até obter uma unidade de implantação diferente.
Passos seguintes
Saiba como ligar um certificado Personalizado TLS/SSL ao Serviço de Aplicações.
Proteja um nome DNS personalizado com uma ligação TLS no Serviço de Aplicações Azure
Adicione um certificado TLS/SSL no Serviço de
Aplicações Azure
correção automática. Este artigo mostra-lhe como criar, carregar ou importar um certificado privado ou um
certificado público para o Serviço de Aplicações.
Assim que o certificado for adicionado à sua aplicação ou aplicação de funçãodo App Service, pode garantir um
nome DNS personalizado com ele ou usá-lo no seu códigode aplicação .
A tabela que se segue lista as opções que tem para adicionar certificados no Serviço de Aplicações:
OPÇ ÃO DESC RIÇ Ã O
Criar um Certificado gerido por serviço de aplicações Um certificado privado que é fácil de usar www se apenas
gratuito (Pré-visualização) precisar de garantir o seu domínio personalizado ou
qualquer domínio não nu no Serviço de Aplicações.
Comprar um certificado de serviço de aplicações Um certificado privado que é gerido pelo Azure. Combina a
simplicidade da gestão automatizada de certificados e a
flexibilidade das opções de renovação e exportação.
Importar um certificado da Key Vault Útil se utilizar o Cofre de Chaves Azure para gerir os seus
certificados PKCS12. Ver requisitos de certificado privado.
Faça upload de um certificado privado Se já tem um certificado privado de um fornecedor de

terceiros, pode carregá-lo. Ver requisitos de certificado
privado.
Faça upload de um certificado público Os certificados públicos não são usados para proteger
domínios personalizados, mas pode carregá-los no seu
código se precisar deles para aceder a recursos remotos.
Pré-requisitos
Criar uma aplicação de Serviço de Aplicações.
Certificado gratuito apenas: mapear um www.contoso.com subdomínio (por exemplo, ) para o Serviço de
Aplicações com um registo CNAME.
Requisitos de certificados privados

NOTE
As Aplicações Web Azure não suportam o AES256 e todos os ficheiros pfx devem ser encriptados com TripleDES.
O Certificado Gerido pelo Serviço de Aplicações gratuito ou o certificado de Serviço de Aplicações já satisfazem
os requisitos do Serviço de Aplicações. Se optar por fazer o upload ou importar um certificado privado para o
Serviço de Aplicações, o seu certificado deve satisfazer os seguintes requisitos:
Exportado como um ficheiro PFX protegido por palavra-passe
Conter uma chave privada com, pelo menos, 2048 bits de comprimento
Conter todos os certificados intermédios na cadeia de certificados
Para garantir um domínio personalizado numa ligação TLS, o certificado tem requisitos adicionais:
Contém uma utilização de chave estendida para autenticação do servidor (OID = 1.3.6.1.5.5.7.3.1)
Ser assinado por uma autoridade de certificação fidedigna
NOTE
Os cer tificados de criptografia de cur va elíptica (ECC) podem funcionar com o Serviço de Aplicações, mas não são
abordados neste artigo. Trabalhe com a sua autoridade de certificados para saber quais são os passos exatos para criar
certificados ECC.

Para criar encadernações de segurança personalizadas ou ativar certificados de cliente para a sua app App
Service, o seu plano de Serviço de Aplicações deve estar no nível Básico , Standard , Premium ou Isolado.
Neste passo, vai confirmar que a aplicação Web está no escalão de preço suportado.

No painel de navegação esquerdo da página da aplicação Web, desloque-se para a secção Definições e
selecione Aumentar ver ticalmente (plano do Ser viço de Aplicações) .
caixa azul-escura.
passos na secção seguinte. Caso contrário, feche a página Scale up e salte a secção de plano seletiva para cima.
Selecione qualquer uma das camadas não gratuitas (B1 , B2 , B3 ou qualquer camada na categoria Produção ).
Para obter opções adicionais, clique em Ver opções adicionais .
Clique em Aplicar .
Criar um certificado gratuito (Pré-visualização)

O Certificado Gerido pelo Serviço de Aplicações gratuito é uma solução chave-na-mão para garantir o seu nome
DNS personalizado no Serviço de Aplicações. É um certificado TLS/SSL totalmente funcional que é gerido pelo
App Service e renovado automaticamente. O certificado gratuito vem com as seguintes limitações:
Não suporta certificados wildcard.
Não suporta domínios nus.
Não é exportável.
Não suporta registos DNS A.
NOTE
O certificado gratuito é emitido pela DigiCert. Para alguns domínios de alto nível, deve permitir explicitamente a DigiCert
como 0 issue digicert.com emitente de certificado, criando um registo de domínio CAA com o valor: .
Para criar um Certificado gerido por serviço de aplicações gratuito:

A partir da navegação à esquerda da sua aplicação, selecione > Configurações TLS/SSL****Cer tificados de
chave privados (.pfx) > Criar certificado gerido pelo serviço deaplicações .
Qualquer domínio não-nu devidamente mapeado para a sua aplicação com um registo CNAME está listado no
diálogo. Selecione o domínio personalizado para criar um certificado gratuito e selecione Criar . Pode criar
apenas um certificado para cada domínio personalizado suportado.
Quando a operação estiver concluída, consulte o certificado na lista de Cer tificados de Chave Privada.
IMPORTANT
Para garantir um domínio personalizado com este certificado, ainda precisa de criar um certificado vinculativo. Siga os
passos em Criar encadernação.
Importar um Certificado de Serviço de Aplicações

Se comprar um Certificado de Serviço de Aplicações à Azure, o Azure gere as seguintes tarefas:
Cuida do processo de compra do GoDaddy.
Realiza verificação de domínio do certificado.
Mantém o certificado no Cofre de Chaves Azure.
Gere a renovação do certificado (ver Certificado Renovar).
Sincronizar automaticamente o certificado com as cópias importadas nas aplicações do App Service.
Para comprar um certificado de Serviço de Aplicações, vá iniciar a encomenda de certificado.
Se já tem um certificado de serviço de aplicações em funcionamento, pode:
Importar o certificado para o Serviço de Aplicações.
Gerir o certificado, como renovar, rekey e exportá-lo.
Iniciar a encomenda de certificado
Inicie uma encomenda de certificado de serviço de aplicações no Certificado de Serviço de Aplicações criar
página.
Utilize a tabela seguinte para o ajudar a configurar o certificado. Quando terminar, clique em Criar .
Nome Um nome amigável para o seu certificado de Serviço de

Aplicações.
Nome do anfitrião do domínio nu Especifique o domínio raiz aqui. O certificado emitido

assegura tanto o www domínio radicular como o
subdomínio. No certificado emitido, o campo Nome Comum
contém o domínio raiz, e o campo Nome Alternativo sujeito
contém o www domínio. Para fixar apenas qualquer
subdomínio, especifique o nome mysubdomain.contoso.com
de domínio totalmente qualificado do subdomínio aqui (por
exemplo, ).
Subscrição A subscrição que conterá o certificado.
Grupo de recursos O grupo de recursos que conterá o certificado. Pode utilizar

um novo grupo de recursos ou selecionar o mesmo grupo
de recursos que a sua app App Service, por exemplo.
Certificado SKU Determina o tipo de certificado a criar, seja um certificado

padrão ou um certificado wildcard.
Termos Legais Clique para confirmar que concorda com os termos legais.
Os certificados são obtidos do GoDaddy.
Loja em Cofre chave Azure

Uma vez concluído o processo de compra do certificado, há mais alguns passos que precisa de completar antes
de começar a usar este certificado.
Selecione o certificado na página de Certificados de Serviço de Aplicações e, em seguida, clique em Passo de
Configuração > do Certificado1: Armazenar .
Key Vault é um serviço Azure que ajuda a salvaguardar chaves criptográficas e segredos usados por aplicações e
serviços em nuvem. É o armazenamento de eleição para certificados de serviço de aplicações.
Na página key vault status, clique no Repositório key vault para criar um novo cofre ou escolha um cofre
existente. Se optar por criar um novo cofre, utilize a tabela seguinte para o ajudar a configurar o cofre e clique
em Criar. Crie o novo Key Vault dentro do mesmo grupo de subscrição e recursos que a sua app App Service.
Nome Um nome único que consiste em caracteres alfanuméricos e

traços.
Grupo de recursos Como recomendação, selecione o mesmo grupo de recursos

que o seu certificado de Serviço de Aplicações.
Localização Selecione o mesmo local que a sua aplicação App Service.

Escalão de preço Para obter informações, consulte os detalhes dos preços do

Cofre chave Azure.
Políticas de acesso Define as aplicações e o acesso permitido aos recursos do

cofre. Pode configurá-lo mais tarde, seguindo os passos da
Grant várias aplicações acesso a um cofre chave.
Acesso à Rede Virtual Restringir o acesso ao cofre a certas redes virtuais azure.
Pode configurá-lo mais tarde, seguindo os passos em
Configurar Firewalls e Redes Virtuais
Assim que escolhero cofre, feche a página de Repositório do Cofre chave. O passo 1: A opção loja deve
mostrar uma marca de verificação verde para o sucesso. Mantenha a página aberta para o próximo passo.
Verificar a propriedade do domínio
A partir da mesma página de Configuração de Certificado que usou no último passo, clique no passo 2:
Verificar .
Selecione Verificação de Ser viço de Aplicações . Uma vez que já mapeou o domínio para a sua aplicação web
(ver Pré-requisitos),já está verificado. Basta clicar em Verificar para terminar este passo. Clique no botão
'Actualizar' até aparecer o Certificado de mensagem Verificado por domínio.
NOTE
São apoiados quatro tipos de métodos de verificação de domínios:
Serviço de Aplicações - A opção mais conveniente quando o domínio já está mapeado para uma aplicação do App
Service na mesma subscrição. Aproveita o facto de a aplicação app Service já ter verificado a propriedade do domínio.
Domínio - Verifique um domínio do Serviço de Aplicações que adquiriu ao Azure. O Azure adiciona automaticamente
o registo TXT de verificação para si e completa o processo.
Correio - Verifique o domínio enviando um e-mail ao administrador de domínio. As instruções são fornecidas quando
selecionar a opção.
Manual - Verifique o domínio utilizando uma página HTML (apenas um certificadoPadrão) ou um registo DNS TXT. As
instruções são fornecidas quando selecionar a opção.
Certificado de importação em Serviço de Aplicações

chave privadas (.pfx) > Certificado de serviço deaplicações de impor tação .
Selecione o certificado que acabou de comprar e selecione OK .

IMPORTANT
Importar um certificado da Key Vault

Se utilizar o Cofre de Chaves Azure para gerir os seus certificados, pode importar um certificado PKCS12 do Key
Vault para o Serviço de Aplicações, desde que satisfaça os requisitos.
chave privadas (.pfx) > Certificado de cofre dechave de impor tação .
Utilize a tabela seguinte para o ajudar a selecionar o certificado.
Subscrição A assinatura a que pertence o Cofre Chave.
Cofre de Chaves O cofre com o certificado que quer importar.
Certificado Selecione na lista de certificados PKCS12 no cofre. Todos os

certificados PKCS12 no cofre estão listados com as suas
impressões digitais, mas nem todos são suportados no
Quando a operação estiver concluída, consulte o certificado na lista de Cer tificados de Chave Privada. Se a
importação falhar com um erro, o certificado não satisfaz os requisitos parao Serviço de Aplicações .
IMPORTANT
Faça upload de um certificado privado

Assim que obtiver um certificado do seu fornecedor de certificados, siga os passos nesta secção para o preparar
para o Serviço de Aplicações.
Intercalar certificados intermédios
Se a sua autoridade de certificação lhe der vários certificados na cadeia de certificados, terá de intercalá-los por
ordem.
Para tal, abra cada certificado recebido num editor de texto.
Crie um ficheiro para o certificado intercalado, denominado mergedcertificate.crt. Num editor de texto, copie o
conteúdo de cada certificado para este ficheiro. A ordem dos seus certificados deve seguir a ordem na cadeia de
certificados, a começar no seu certificado e a terminar no certificado de raiz. O aspeto é igual ao do exemplo
abaixo:
-----BEGIN CERTIFICATE-----
<your entire Base64 encoded SSL certificate>
-----END CERTIFICATE-----
<The entire Base64 encoded intermediate certificate 1>
<The entire Base64 encoded intermediate certificate 2>
<The entire Base64 encoded root certificate>
Exportar o certificado para PFX

Exporte o seu certificado TLS/SSL fundido com a chave privada com a que o seu pedido de certificado foi
gerado.
Se tiver gerado o pedido de certificado com OpenSSL, significa que criou um ficheiro de chave privada. Para
exportar o certificado para PFX, execute o seguinte comando. Substitua os _ <porta-chaves-reservados>_ e _
<>_ de ficheiros de certificados fundidos com os caminhos da sua chave privada e o seu ficheiro de certificado
fundido.
openssl pkcs12 -export -out myserver.pfx -inkey <private-key-file> -in <merged-certificate-file>
Quando lhe for pedido, defina uma palavra-passe de exportação. Utilizará esta palavra-passe ao enviar o seu
certificado TLS/SSL para o Serviço de Aplicações mais tarde.
Se tiver utilizado o IIS ou Certreq.exe para gerar o pedido de certificado, instale o certificado no seu computador
local e exporte-o para PFX.
Enviar certificado para o Serviço de Aplicações
Está agora pronto para carregar o certificado para o Serviço de Aplicações.
A partir da navegação à esquerda da sua aplicação, selecione > Configurações
TLS/SSL****Cer tificados dechave privados (.pfx) > Certificado de upload .
Em Ficheiro de Cer tificado PFX , selecione o ficheiro PFX. Em Palavra-passe do cer tificado , escreva a
palavra-passe que criou quando exportou o ficheiro PFX. Quando terminar, clique em Carregar .
IMPORTANT
Faça upload de um certificado público

Os certificados públicos são suportados no formato .cer.
A partir da navegação à esquerda da sua aplicação, clique em > definições TLS/SSL****Cer tificados
públicos (.cer) > Carregar Cer tificado de Chave Pública .
Em Nome, digite um nome para o certificado. No ficheiro Cer Cer tificate, selecione o ficheiro CER.
Clique em Carregar .
Uma vez carregado o certificado, copie a impressão digital do certificado e consulte Tornar o certificado
acessível.
Gerir certificados de serviço de aplicações

Esta secção mostra-lhe como gerir um certificado de Serviço app que adquiriu na Importação de um certificado
de Serviço de Aplicações.
Certificado de rechave
Renovar certificado
Exportar o certificado
Excluir certificado
Certificado de rechave
Se acha que a chave privada do seu certificado está comprometida, pode re-chave o seu certificado. Selecione o
certificado na página de Certificados de Serviço de Aplicações e, em seguida, selecione Rekey e Sync da
navegação esquerda.
Clique em Rekey para iniciar o processo. Este processo pode levar 1-10 minutos para ser concluído.
Resqueifique o certificado, o certificado passa o certificado com um novo certificado emitido pela autoridade do
certificado.
Assim que o funcionamento da chave estiver concluído, clique em Sync . A operação de sincronização atualiza
automaticamente as encadernações do nome de anfitrião para o certificado no Serviço de Aplicações sem causar
qualquer inatividade nas suas apps.
NOTE
Se não clicar em Sync, o Serviço de Aplicações sincroniza automaticamente o seu certificado dentro de 48 horas.
Renovar certificado
Para ativar a renovação automática do seu certificado a qualquer momento, selecione o certificado na página de
Certificados de Serviço de Aplicações e, em seguida, clique em Definições de Renovação Automática na
navegação à esquerda. Por padrão, os Certificados de Serviço de Aplicações têm um período de validade de um
ano.
Selecione On e clique em Guardar . Os certificados podem começar a renovar automaticamente 60 dias antes
da expiração se tiver a renovação automática ligada.
Para renovar manualmente o certificado, clique em Renovar Manual . Pode solicitar a renovação manual do seu
certificado 60 dias antes da expiração.
Assim que a operação de renovação estiver concluída, clique em Sync . A operação de sincronização atualiza
automaticamente as encadernações do nome de anfitrião para o certificado no Serviço de Aplicações sem causar
qualquer inatividade nas suas apps.
NOTE
Se não clicar em Sync, o Serviço de Aplicações sincroniza automaticamente o seu certificado dentro de 48 horas.
Exportar o certificado
Como um Certificado de Serviço de Aplicações é um segredo key vault,você pode exportar uma cópia PFX do
mesmo e usá-lo para outros serviços Azure ou fora de Azure.
Para exportar o Certificado de Serviço de Aplicações como ficheiro PFX, execute os seguintes comandos na
Cloud Shell. Também pode executá-lo localmente se instalou o Azure CLI. Substitua os espaços reservados pelos
nomes utilizados quando criou o certificado de Serviço de Aplicações.
secretname=$(az resource show \

--resource-group <group-name> \
--resource-type "Microsoft.CertificateRegistration/certificateOrders" \
--name <app-service-cert-name> \
--query "properties.certificates.<app-service-cert-name>.keyVaultSecretName" \
--output tsv)
az keyvault secret download \

--file appservicecertificate.pfx \
--vault-name <key-vault-name> \
--name $secretname \
--encoding base64
O ficheiro appservicecertificate.pfx descarregado é um ficheiro PKCS12 cru que contém certificados públicos e
privados. Em cada pedido, utilize uma corda vazia para a palavra-passe de importação e a frase de passe PEM.
Excluir certificado
A eliminação de um certificado de Serviço de Aplicações é definitiva e irreversível. A eliminação de um recurso
do Certificado de Serviço de Aplicações resulta na revogação do certificado. Qualquer encadernação no Serviço
de Aplicações com este certificado torna-se inválida. Para evitar a supressão acidental, o Azure coloca um
cadeado no certificado. Para eliminar um certificado de Serviço de Aplicações, tem primeiro de remover o
bloqueio de eliminação do certificado.
Selecione o certificado na página de Certificados de Serviço de Aplicações e, em seguida, selecione Locks na
navegação à esquerda.
Encontre o cadeado no seu certificado com o tipo de bloqueio Delete . À direita, selecione Delete .
Agora pode eliminar o certificado de Serviço de Aplicações. A partir da navegação à esquerda, selecione Visão
Geral > Delete . No diálogo de confirmação, escreva o nome do certificado e selecione OK .
CLI do Azure
#!/bin/bash
fqdn=<replace-with-www.{yourdomain}>
pfxPath=<replace-with-path-to-your-.PFX-file>
pfxPassword=<replace-with-your=.PFX-password>
resourceGroup=myResourceGroup
webappname=mywebapp$RANDOM

az group create --location westeurope --name $resourceGroup
# Create an App Service plan in Basic tier (minimum required by custom domains).
az appservice plan create --name $webappname --resource-group $resourceGroup --sku B1
# Create a web app.

az webapp create --name $webappname --resource-group $resourceGroup \
--plan $webappname
echo "Configure a CNAME record that maps $fqdn to $webappname.azurewebsites.net"

read -p "Press [Enter] key when ready ..."
# Map your prepared custom domain name to the web app.

az webapp config hostname add --webapp-name $webappname --resource-group $resourceGroup \
--hostname $fqdn
# Upload the SSL certificate and get the thumbprint.

thumbprint=$(az webapp config ssl upload --certificate-file $pfxPath \
--certificate-password $pfxPassword --name $webappname --resource-group $resourceGroup \
--query thumbprint --output tsv)
# Binds the uploaded SSL certificate to the web app.

az webapp config ssl bind --certificate-thumbprint $thumbprint --ssl-type SNI \
--name $webappname --resource-group $resourceGroup
echo "You can now browse to https://$fqdn"
PowerShell
$fqdn="<Replace with your custom domain name>"
$pfxPath="<Replace with path to your .PFX file>"
$pfxPassword="<Replace with your .PFX password>"
$webappname="mywebapp$(Get-Random)"
$location="West Europe"

New-AzResourceGroup -Name $webappname -Location $location

New-AzAppServicePlan -Name $webappname -Location $location `
-ResourceGroupName $webappname -Tier Free
# Create a web app.

New-AzWebApp -Name $webappname -Location $location -AppServicePlan $webappname `
-ResourceGroupName $webappname
Write-Host "Configure a CNAME record that maps $fqdn to $webappname.azurewebsites.net"

Read-Host "Press [Enter] key when ready ..."
# Upgrade App Service plan to Basic tier (minimum required by custom SSL certificates)
Set-AzAppServicePlan -Name $webappname -ResourceGroupName $webappname `
-Tier Basic
# Add a custom domain name to the web app.

Set-AzWebApp -Name $webappname -ResourceGroupName $webappname `
-HostNames @($fqdn,"$webappname.azurewebsites.net")
# Upload and bind the SSL certificate to the web app.

New-AzWebAppSSLBinding -WebAppName $webappname -ResourceGroupName $webappname -Name $fqdn `
-CertificateFilePath $pfxPath -CertificatePassword $pfxPassword -SslState SniEnabled
Mais recursos
Impor HTTPS
Impor TLS 1.1/1.2
Utilize um certificado TLS/SSL no seu código no Serviço de Aplicações Azure
Configure o seu app service ou app Funções Azure
para usar login Azure AD
Este artigo mostra-lhe como configurar o Azure App Service ou as Funções Azure para utilizar o Azure Ative
Directory (Azure AD) como fornecedor de autenticação.
NOTE
O fluxo de definições expressas configura um registo de aplicação AAD V1. Se desejar utilizar o Diretório Ativo Azure v2.0
(incluindo o MSAL),siga as instruções avançadasde configuração .
Siga estas boas práticas ao configurar a sua app e autenticação:

Dê a cada app do App Service as suas próprias permissões e consentimento.
Configure cada app do App Service com o seu próprio registo.
Evite a partilha de permissões entre ambientes utilizando registos de aplicações separados para slots de
implementação separados. Ao testar um novo código, esta prática pode ajudar a evitar que problemas
afetem a aplicação de produção.
NOTE
Esta funcionalidade não está atualmente disponível no plano de consumo linux para funções azure
Configure com configurações expressas

NOTE
A opção Express não está disponível para nuvens governamentais.
1. No [portal Azure,]procure e selecione Ser viços de Aplicações e, em seguida, selecione a sua aplicação.
2. A partir da navegação à esquerda, selecione Autenticação / Autorização > On .
3. Selecione Azure Ative Director y > Express .
Se quiser escolher um registo de aplicação existente:
a. Escolha a aplicação AD existente e, em seguida, clique na aplicação AD Azure .
b. Escolha o registo de uma aplicação existente e clique em OK .
4. Selecione OK para registar a app Service no Diretório Ativo Azure. É criado um novo registo de
aplicações.
5. (Opcional) Por padrão, o Serviço de Aplicações fornece a autenticação, mas não restringe o acesso
autorizado aos conteúdos e APIs do seu site. Tem de autorizar os utilizadores no seu código de
aplicações. Para restringir o acesso à aplicação apenas aos utilizadores autenticados pelo Diretório Ativo
do Azure, deteteto a Ação a tomar quando o pedido não for autenticado para iniciar sessão com o
Diretório Ativo do Azure . Ao definir esta funcionalidade, a sua aplicação requer que todos os pedidos
sejam autenticados. Também redireciona todos os não autenticados para o Diretório Ativo Azure para
autenticação.
Cau t i on
Restringir o acesso desta forma aplica-se a todas as chamadas para a sua app, o que pode não ser
desejável para aplicações que tenham uma página inicial disponível ao público, como em muitas
aplicações de página única. Para tais aplicações, permitir pedidos anónimos (nenhuma ação) pode
ser preferido, com a aplicação a iniciar o login manualmente em si. Para mais informações, consulte o
fluxo de autenticação.
Configurar com configurações avançadas

Pode configurar manualmente as definições de aplicações se pretender utilizar um registo de aplicações de um
inquilino Azure AD diferente. Para completar esta configuração personalizada:
1. Crie uma inscrição em Azure AD.
2. Forneça alguns dos dados de registo ao Serviço de Aplicações.
Crie um registo de aplicativos no Azure AD para a sua app App Service
Necessitará das seguintes informações quando configurar a sua aplicação de Serviço de Aplicações:
ID de Cliente
ID do inquilino
Segredo do cliente (opcional)
ID de aplicação URI
Execute os seguintes passos:
1. Inscreva-se no [portal Azure,]procure e selecione Ser viços de Aplicações, e depois selecione a sua
aplicação. Tenha em anotao o URL da sua aplicação. Irá usá-lo para configurar o registo da sua aplicação
Azure Ative Directory.
2. Selecione Registos de Aplicações de Diretório Ativo Azure Novas > App registrations > inscrições .
3. Na página do Registo de inscrição, insira um Nome para o registo da sua aplicação.
4. Em Redirecione URI, selecione Web e escreva <app-url>/.auth/login/aad/callback . Por exemplo,
https://contoso.azurewebsites.net/.auth/login/aad/callback .
5. Selecione Criar .
6. Após a criação do registo da aplicação, copie o ID da Aplicação (cliente) e o ID do Diretório
(inquilino) para mais tarde.
7. Selecione Autenticação . Sob a subvenção Implícita, ative fichas de ID para permitir o openID
Connect user sign-ins do Serviço de Aplicações.
8. (Opcional) Selecione Branding . No URL da página inicial, introduza o URL da sua aplicação App
Service e selecione Guardar .
9. Selecione Expor um conjunto API > Set . Para aplicativo de inquilino único, colhe no URL da sua app App
Service e selecione Save e para aplicação multi-inquilino, cola no URL que é baseado em um dos
domínios verificados pelo inquilino e, em seguida, selecione Save .
NOTE
Este valor é o ID DE Aplicação URI do registo da aplicação. Se a sua aplicação web necessitar de acesso a uma
API na nuvem, precisa do ID URI da aplicação web quando configurar o recurso cloud App Service. Pode usá-lo,
por exemplo, se quiser que o serviço de nuvem conceda explicitamente acesso à aplicação web.
10. Selecione Adicionar âmbito .

a. No nome Scope, introduza user_impersonation.
b. Nas caixas de texto, introduza o nome e descrição do âmbito de consentimento que pretende que os
utilizadores vejam na página de consentimento. Por exemplo, insira Aceder à minha aplicação.
c. Selecione Adicionar âmbito .
11. (Opcional) Para criar um segredo de cliente, selecione Cer tificados & segredos > Novo segredo do
cliente > Adicionar . Copie o valor secreto do cliente mostrado na página. Não voltará a ser mostrado.
12. (Opcional) Para adicionar vários URLs de Resposta, selecione Autenticação .
Ativar o Diretório Ativo Azure na sua app App Service
1. No [portal Azure,]procure e selecione Ser viços de Aplicações e, em seguida, selecione a sua aplicação.
2. No painel esquerdo, em Definições, selecione Autenticação / Autorização > Ligado .
3. (Opcional) Por defeito, a autenticação do Serviço de Aplicações permite o acesso não autenticado à sua
aplicação. Para impor a autenticação do utilizador, detete a Ação a tomar quando o pedido não for
autenticado para iniciar sessão com o Diretório Ativo Azure .
4. No âmbito dos Fornecedores de Autenticação, selecione Diretório Ativo Azure .
5. No modo de Gestão, selecione autenticação avançada e configure o Serviço de Aplicações de acordo
com a tabela seguinte:
CAMPO DESC RIÇ Ã O

CAMPO DESC RIÇ Ã O
ID de Cliente Utilize a identificação da Aplicação (cliente) do registo

da aplicação.
Url de emitente Utilize , e substitua o

<authentication-endpoint>/<tenant-id>/v2.0 ponto
final da * < autenticação>* pelo ponto final de
autenticação para o seu ambiente em nuvem (por
exemplo, https://login.microsoft.com " para o Global
Azure), substituindo também * <>de identificação de
inquilinos* pelo ID do Diretório (inquilino) no qual foi
criado o registo da aplicação. Este valor é utilizado para
redirecionar os utilizadores para o inquilino da AD Azure
correto, bem como para descarregar os metadados
apropriados para determinar as chaves de assinatura
simbólicas apropriadas e o valor de reclamação de
emitente simbólico, por exemplo. A /v2.0 secção pode
ser omitida para aplicações utilizando AAD v1.
Segredo de Cliente (Opcional) Use o segredo do cliente gerado no registo da aplicação.
Audiências simbólicas permitidas Se se trata de uma aplicação de nuvem ou servidor e

pretende permitir fichas de autenticação a partir de uma
aplicação web, adicione o ID URI da aplicação web aqui.
O ID do cliente configurado é sempre considerado
implicitamente como um público permitido.
6. Selecione OK , e, em seguida, selecione Guardar .

Está agora pronto para utilizar o Diretório Ativo Azure para autenticação na sua aplicação App Service.
Configurar uma aplicação de cliente nativo

Pode registar clientes nativos para permitir a autenticação na Web API's hospedada na sua aplicação utilizando
uma biblioteca de clientes como a Biblioteca de Autenticação de DirectórioAtivo Ativo.
1. No [portal Azure,]selecione Registos de Aplicações de Diretório Ativo > App registrations > Novo
registo.
2. Na página do Registo de inscrição, insira um Nome para o registo da sua aplicação.
3. No Redirect URI, selecione cliente público (mobile & desktop) e escreva o URL
<app-url>/.auth/login/aad/callback . Por exemplo,
https://contoso.azurewebsites.net/.auth/login/aad/callback .
NOTE
Para uma aplicação da Microsoft Store, utilize o pacote SID como URI.
5. Após a criação do registo da aplicação, copie o valor do ID da Aplicação (cliente).
6. Selecione permissões API > Adicione uma permissão > As minhas APIs .
7. Selecione o registo de aplicações que criou anteriormente para a sua aplicação App Service. Se não vir o
registo da aplicação, certifique-se de que adicionou o âmbito de user_impersonation em Criar uma
inscrição de aplicação no Azure AD paraa sua app App Service .
8. Sob permissões delegadas, selecione user_impersonation , e, em seguida, selecione Adicionar
permissões .
Já configurou uma aplicação de cliente nativo que pode aceder à sua aplicação de Serviço de Aplicações em
nome de um utilizador.
Configure uma aplicação de cliente daemon para chamadas de

serviço a serviço
A sua aplicação pode adquirir um símbolo para chamar uma API Web hospedada na sua app De Serviço ou
Função de Aplicação (não em nome de um utilizador). Este cenário é útil para aplicações daemon não interativas
que executam tarefas sem um registo registado no utilizador. Usa a bolsa padrão de credenciais de clientes
OAuth 2.0.
1. No [portal Azure,]selecione Registos de Aplicações de Diretório Ativo > App registrations > Novo
registo.
2. Na página do Registo de uma aplicação, insira um Nome para o registo da sua aplicação daemon.
3. Para uma aplicação daemon, você não precisa de um Uri Redirecion para que possa manter isso vazio.
5. Após a criação do registo da aplicação, copie o valor do ID da Aplicação (cliente).
6. Selecione Cer tificados & segredos > Novo segredo do cliente > Adicionar . Copie o valor secreto do
cliente mostrado na página. Não voltará a ser mostrado.
Pode agora solicitar um sinal de acesso utilizando o ID do cliente e o segredo do cliente, definindo o parâmetro
para o ID DE resource Aplicação URI da aplicação alvo. O token de acesso resultante pode então ser
apresentado à app-alvo utilizando o cabeçalho de autorização padrão OAuth 2.0, e a Autenticação/Autorização
do Serviço de Aplicações validará e utilizará o símbolo como de costume para indicar agora que o chamador
(uma aplicação neste caso, não um utilizador) é autenticado.
Atualmente, isto permite que qualquer aplicação de cliente no seu inquilino Azure AD solicite um token de
acesso e autenticar a app alvo. Se também pretende impor autorização para permitir apenas determinadas
aplicações de clientes, deve realizar alguma configuração adicional.
1. Defina uma Função de Aplicação no manifesto do registo da aplicação que representa o Serviço de
Aplicações ou app 'Função' que pretende proteger.
2. No registo da aplicação que representa o cliente que precisa de ser autorizado, selecione permissões API >
Adicione uma permissão > As minhas APIs .
3. Selecione o registo da aplicação que criou anteriormente. Se não vir o registo da aplicação, certifique-se de
que adicionou uma Função de Aplicação.
4. Sob permissões de Aplicação, selecione a Função app que criou anteriormente e, em seguida, selecione
Adicionar permissões .
5. Certifique-se de clicar no consentimento do administrador da Grant para autorizar o pedido do cliente
para solicitar a permissão.
6. À semelhança do cenário anterior (antes de serem adicionadas quaisquer funções), pode agora solicitar um
sinal de acesso para o mesmo alvo , e o sinal de acesso incluirá uma resource reclamação contendo as
Funções de roles Aplicação que foram autorizadas para a aplicação do cliente.
7. Dentro do código de aplicação target App Service ou Função, pode agora validar que as funções esperadas
estão presentes no token (isto não é executado por Autenticação/Autorização do Serviço de Aplicação). Para
mais informações, consulte as reclamações dos utilizadoresdo Access.
Já configurou uma aplicação de cliente daemon que pode aceder à sua aplicação App Service usando a sua
própria identidade.
Próximos passos
Autenticação do serviço de aplicações / visão geral da autorização.
Utilização avançada de autenticação e autorização no Serviço de Aplicações Azure
Tutorial: Autenticar e autorizar utilizadores ponto a ponto no Serviço de Aplicações do Azure
Adicione a autenticação à sua Aplicação Móvel: iOS, Android, Windows Universal, Xamarin.Android,
Xamarin.iOS, Xamarin.Forms, Cordova.
para usar login no Facebook
Este artigo mostra como configurar o Azure App Service ou o Azure Functions para usar o Facebook como
fornecedor de autenticação.
Para completar o procedimento neste artigo, precisa de uma conta no Facebook que tenha um endereço de e-
mail verificado e um número de telemóvel. Para criar uma nova conta no Facebook, vá para facebook.com.
Registe a sua aplicação no Facebook

1. Vá ao site do Facebook Developers e inscreva-se nas credenciais da sua conta do Facebook.
Se não tiver uma conta no Facebook para Desenvolvedores, selecione Get Star ted e siga as etapas de
registo.
2. Selecione As minhas aplicações > Adicionar nova aplicação .
3. No campo nome do ecrã:
a. Escreva um nome único para a sua aplicação.
b. Forneça o seu Email de Contacto .
c. Selecione Criar id de aplicativo .
d. Complete a verificação de segurança.
O painel de desenvolvedores da sua nova aplicação do Facebook abre.
4. Selecione Dashboard > Facebook Iniciar sessão > Set up > naWeb .
5. Na navegação à esquerda no Facebook Login, selecione Definições .
6. No campo Deredirect IUrIs De Redirecion AAuth válido, introduza
https://<app-name>.azurewebsites.net/.auth/login/facebook/callback . Lembre-se <app-name> de substituir
pelo nome da sua aplicação Azure App Service.
7. Selecione Guardar Alterações .
8. No painel esquerdo, selecione Definições > Básicas .
9. No campo App Secret, selecione Show . Copie os valores do ID da app e do App Secret. Usa-os mais
tarde para configurar a tua aplicação App Service em Azure.
IMPORTANT
O segredo da aplicação é uma importante credencial de segurança. Não partilhe este segredo com ninguém nem o
distribua dentro de uma aplicação de cliente.
10. A conta do Facebook que usou para registar a aplicação é administradora da app. Neste momento, apenas
os administradores podem subscrever esta aplicação.
Para autenticar outras contas do Facebook, selecione App Review e permita tornar ** <** o seu nome de
aplicação> público para permitir ao público em geral aceder à aplicação através da autenticação do
Facebook.
Adicione informações do Facebook à sua aplicação

1. Inscreva-se no [portal Azure] e navegue na sua app App Service.
2. Selecione Definições > Autenticação / Autorização, e certifique-se de que a autenticação do serviço
de aplicações está a ser ressoada . App Ser vice Authentication
3. Selecione facebook , e depois colhe nos valores de ID da app e App Secret que obteve anteriormente.
Ative todos os âmbitos necessários pela sua aplicação.
4. Selecione OK .
Por padrão, o Serviço de Aplicações fornece a autenticação, mas não restringe o acesso autorizado aos
conteúdos e APIs do seu site. Tem de autorizar os utilizadores no seu código de aplicações.
5. (Opcional) Para restringir o acesso apenas aos utilizadores autenticados pelo Facebook, deteto uação a
tomar quando o pedido não for autenticado no Facebook . Ao definir esta funcionalidade, a sua
aplicação requer que todos os pedidos sejam autenticados. Também redireciona todos os pedidos não
autenticados para o Facebook para autenticação.
Cau t i on
ser preferido para que a aplicação comece manualmente a autenticação em si. Para mais informações,
consulte o fluxo de autenticação.
Está agora pronto para usar o Facebook para autenticação na sua aplicação.
Passos seguintes
para usar o login do Google
Este tópico mostra-lhe como configurar o Azure App Service ou as Funções Azure para utilizar o Google como
Para completar o procedimento neste tópico, deve ter uma conta no Google que tenha um endereço de e-mail
verificado. Para criar uma nova conta do Google, aceda a accounts.google.com.
Registe a sua aplicação no Google

1. Siga a documentação do Google no Google Sign-In para aplicações do lado do servidor para criar um ID
do cliente e segredo de cliente. Não há necessidade de fazer alterações de código. Basta utilizar as
seguintes informações:
Para origens JavaScript autorizadas, utilize https://<app-name>.azurewebsites.net com o nome da
sua aplicação no * <nome da aplicação>*.
Para redirecionar URI autorizado, utilize
https://<app-name>.azurewebsites.net/.auth/login/google/callback .
2. Copie o ID da app e os valores secretos da App.
IMPORTANT
O segredo da App é uma importante credencial de segurança. Não partilhe este segredo com ninguém nem o
distribua dentro de uma aplicação de cliente.
Adicione informações do Google à sua aplicação

1. No [portal Azure,]vá à sua app App Service.
3. Selecione Google , em seguida, colá-se nos valores de ID da app e App Secret que obteve anteriormente.
Ative todos os âmbitos necessários pela sua aplicação.
4. Selecione OK .
O Serviço de Aplicações fornece a autenticação, mas não restringe o acesso autorizado aos conteúdos e
APIs do seu site. Para mais informações, consulte Autorizar ou negar aos utilizadores.
5. (Opcional) Para restringir o acesso ao site apenas aos utilizadores autenticados pela Google, detete a
Action totake quando o pedido não for autenticado no Google . Ao definir esta funcionalidade, a
sua aplicação requer que todos os pedidos sejam autenticados. Também redireciona todos os pedidos não
autenticados para a Google para autenticação.
Cau t i on
Está agora pronto para utilizar o Google para autenticação na sua aplicação.
Passos seguintes
para usar login da Conta Microsoft
Este tópico mostra-lhe como configurar o Azure App Service ou as Funções Azure para utilizar a AAD para
suportar logins pessoais da conta da Microsoft.
NOTE
Tanto as contas pessoais da Microsoft como as contas organizacionais utilizam o fornecedor de identidade AAD. Neste
momento, não é possível configurar este fornecedor de identidade para suportar ambos os tipos de login.
Registe a sua aplicação com a Conta Microsoft

1. Vá às inscrições da App no portal Azure. Se necessário, inscreva-se na sua conta Microsoft.
2. Selecione Novo registo e, em seguida, insira um nome de candidatura.
3. Sob os tipos de conta supor tados , selecione Contas em qualquer diretório organizacional
(Qualquer diretório AD Azure - Multitenant) e contas pessoais da Microsoft (por exemplo,
Skype, Xbox)
4. Em Redirecionar URIs, selecione Web , e, em seguida, introduza
https://<app-domain-name>/.auth/login/aad/callback . Substitua>de * < nome de domínio* de aplicativo
com o nome de domínio da sua aplicação. Por exemplo,
https://contoso.azurewebsites.net/.auth/login/aad/callback . Certifique-se de utilizar o esquema HTTPS
no URL.
5. Selecione Registar .
6. Copiar o ID da Aplicação (Cliente) . Precisará dela mais tarde.
7. Do painel esquerdo, selecione Cer tificados & segredos Novo segredo do > cliente. Introduza uma
descrição, selecione a duração da validade e selecione Adicionar .
8. Copie o valor que aparece na página de Cer tificados & segredos. Depois de sair da página, não voltará
a ser exibido.
IMPORTANT
O valor secreto do cliente (senha) é uma importante credencial de segurança. Não partilhe a palavra-passe com
ninguém nem a distribua dentro de uma aplicação do cliente.
Adicione informações da Conta Microsoft à sua aplicação de Serviço

de Aplicações
1. Vá à sua aplicação no [portal Azure.]
de aplicações está a ser ressoada .
3. No âmbito dos Fornecedores de Autenticação, selecione Diretório Ativo Azure . Selecione
Advanced no modo de gestão . Colar no ID de Aplicação (cliente) e no segredo do cliente que obteve
anteriormente. Utilizar https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0 para
o campo Url emitente.
4. Selecione OK .
O Serviço de Aplicações fornece a autenticação, mas não restringe o acesso autorizado aos conteúdos e
APIs do seu site. Tem de autorizar os utilizadores no seu código de aplicações.
5. (Opcional) Para restringir o acesso aos utilizadores da conta da Microsoft, detete toda a Ação quando o
pedido não for autenticado para iniciar sessão com o Diretório Ativo do Azure . Ao definir esta
funcionalidade, a sua aplicação requer que todos os pedidos sejam autenticados. Também redireciona
todos os pedidos não autenticados para a utilização de AAD para autenticação. Note que, uma vez que
configurou o seu Url emitente para utilizar o inquilino da Conta Microsoft, apenas os acréscimos
pessoais irão autenticar com sucesso.
Cau t i on
Está agora pronto para utilizar a Conta Microsoft para autenticação na sua aplicação.
Passos seguintes
para usar o login do Twitter
Este artigo mostra como configurar o Azure App Service ou o Azure Functions para usar o Twitter como
Para completar o procedimento neste artigo, precisa de uma conta no Twitter que tenha um endereço de e-mail
verificado e número de telefone. Para criar uma nova conta no Twitter, vá a twitter.com.
Registe a sua aplicação no Twitter

1. Inscreva-se no [portal Azure] e vá à sua candidatura. Copie o seu URL . Vai usá-lo para configurar a sua
aplicação do Twitter.
2. Vá ao site do [Twitter Developers,] inscreva-se com as credenciais da sua conta do Twitter e selecione
Criar uma aplicação .
3. Insira o nome da App e a descrição da Aplicação para a sua nova aplicação. Colhe o URL da sua
aplicação no campo URL do Site. Na secção DeCallback URLs, introduza o URL HTTPS da
/.auth/login/twitter/callback sua app App Service e aperte o caminho . Por exemplo,
https://contoso.azurewebsites.net/.auth/login/twitter/callback .
4. Na parte inferior da página, digite pelo menos 100 caracteres em Dizer-nos como esta aplicação será
usada e, em seguida, selecione Criar . Clique em Criar novamente no pop-up. Os detalhes da aplicação
são apresentados.
5. Selecione o separador Keys e Access Tokens.
Tome nota destes valores:
Chave API
Chave secreta da API
NOTE
A chave secreta da API é uma importante credencial de segurança. Não partilhe este segredo com ninguém nem o
distribua com a sua aplicação.
Adicione informações do Twitter à sua aplicação

1. Vá à sua aplicação no [portal Azure.]
3. Selecione Twitter .
4. Pasta nos API key valores e API secret key valores que obteve anteriormente.
5. Selecione OK .
Por padrão, o Serviço de Aplicações fornece a autenticação, mas não restringe o acesso autorizado aos
conteúdos e APIs do seu site. Tem de autorizar os utilizadores no seu código de aplicações.
6. (Opcional) Para restringir o acesso ao seu site a apenas utilizadores autenticados pelo Twitter, detete toda
a Ação quando o pedido não for autenticado no Twitter . Ao definir esta funcionalidade, a sua
aplicação requer que todos os pedidos sejam autenticados. Também redireciona todos os pedidos não
autenticados para o Twitter para autenticação.
Cau t i on
Está agora pronto para usar o Twitter para autenticação na sua aplicação.
Passos seguintes
Utilização avançada de autenticação e autorização
no Serviço de Aplicações Azure
Este artigo mostra-lhe como personalizar a autenticação e autorizaçãoincorporadas no Serviço de Aplicações e

gerir a identidade da sua aplicação.
Para começar rapidamente, consulte um dos seguintes tutoriais:
Tutorial: Autenticar e autorizar utilizadores de ponta a ponta no Serviço de Aplicações Azure (Windows)
Tutorial: Autenticar e autorizar utilizadores de ponta a ponta no Serviço de Aplicações Azure para linux
Como configurar a sua aplicação para utilizar o início de sessão do Azure Active Directory
Como configurar a sua aplicação para utilizar o início de sessão do Facebook
Como configurar a sua aplicação para utilizar o início de sessão do Google
Como configurar a sua aplicação para utilizar o início de sessão da conta Microsoft
Como configurar a sua aplicação para utilizar o início de sessão do Twitter
Utilize vários fornecedores de sessão

A configuração do portal não oferece uma forma chave-de-mão de apresentar vários fornecedores de entrada
aos seus utilizadores (como facebook e Twitter). No entanto, não é difícil adicionar a funcionalidade à sua
aplicação. Os passos são delineados da seguinte forma:
Primeiro, na página de Autenticação/Autorização no portal Azure, configure cada um dos fornecedores de
identidade que pretende ativar.
Em Ação a tomar quando o pedido não é autenticado, selecione Permitir pedidos Anónimos (sem ação) .
Na página de sessão, ou na barra de navegação, ou em qualquer outra localização da sua
/.auth/login/<provider> aplicação, adicione um link de sessão a cada um dos fornecedores que ativou (). Por
exemplo:
<a href="/.auth/login/aad">Log in with Azure AD</a>

<a href="/.auth/login/microsoftaccount">Log in with Microsoft Account</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/twitter">Log in with Twitter</a>
Quando o utilizador clica num dos links, a respetiva página de sessão abre-se para iniciar sessão no utilizador.
Para redirecionar o utilizador pós-login para um post_login_redirect_url URL personalizado, utilize o
parâmetro de corda de consulta (não confundir com o Redirect URI na configuração do seu fornecedor de
identidade). Por exemplo, para navegar /Home/Index o utilizador para depois do iniciar sessão, utilize o seguinte
código HTML:
<a href="/.auth/login/<provider>?post_login_redirect_url=/Home/Index">Log in</a>
Validar fichas de fornecedores

Num login dirigido pelo cliente, a aplicação assina manualmente no utilizador ao fornecedor e, em seguida,
submete o símbolo de autenticação ao Serviço de Aplicações para validação (ver fluxo de autenticação). Esta
validação em si não lhe dá acesso aos recursos de aplicações desejados, mas uma validação bem sucedida lhe
dará um sinal de sessão que pode usar para aceder aos recursos da aplicação.
Para validar o token do fornecedor, a aplicação App Service deve primeiro ser configurada com o fornecedor
pretendido. No tempo de execução, depois de recuperar o símbolo de /.auth/login/<provider> autenticação do
seu fornecedor, poste o token para validação. Por exemplo:
POST https://<appname>.azurewebsites.net/.auth/login/aad HTTP/1.1

Content-Type: application/json
{"id_token":"<token>","access_token":"<token>"}
O formato simbólico varia ligeiramente de acordo com o fornecedor. Consulte a tabela seguinte para mais
detalhes:
VA LO R DO F O RN EC EDO R O B RIGATÓ RIO N O Ó RGÃ O DE P EDIDO C O M EN TÁ RIO S
aad {"access_token":"
<access_token>"}
microsoftaccount {"access_token":"<token>"} A expires_in propriedade é

opcional.
Ao solicitar o sinal dos serviços
wl.basic ao vivo, solicite sempre o
âmbito.
google {"id_token":"<id_token>"} A authorization_code propriedade é

opcional. Quando especificado,
também pode ser acompanhado
redirect_uri opcionalmente pela
propriedade.
facebook {"access_token":" Utilize um sinal de acesso válido ao

<user_access_token>"} utilizador do Facebook.
twitter {"access_token":"
<access_token>",
"access_token_secret":"
<acces_token_secret>"}
Se o token do fornecedor for validado com authenticationToken sucesso, a API devolve com um no corpo de
resposta, que é o seu símbolo de sessão.
{
"authenticationToken": "...",
"user": {
"userId": "sid:..."
}
}
Assim que tiver esta ficha de sessão, pode X-ZUMO-AUTH aceder aos recursos de aplicações protegidos
adicionando o cabeçalho aos seus pedidos HTTP. Por exemplo:
GET https://<appname>.azurewebsites.net/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>
Assine fora de uma sessão

Os utilizadores podem iniciar uma GET inscrição enviando /.auth/logout um pedido para o ponto final da
aplicação. O GET pedido faz o seguinte:
Limpa os cookies de autenticação da sessão atual.
Elimina as fichas do utilizador atual da loja de fichas.
Para o Azure Ative Directory e google, realiza uma inscrição do lado do servidor no fornecedor de identidade.
Esta é uma ligação simples de fim de sessão numa página Web:
<a href="/.auth/logout">Sign out</a>
Por predefinição, um sinal de saída bem /.auth/logout/done sucedido redireciona o cliente para o URL . Pode
alterar a página de redirecionamento post_logout_redirect_uri pós-inscrição adicionando o parâmetro de
consulta. Por exemplo:
GET /.auth/logout?post_logout_redirect_uri=/index.html
Recomenda-se que codifique o post_logout_redirect_uri valor de.

Ao utilizar URLs totalmente qualificados, o URL deve ser hospedado no mesmo domínio ou configurado como
um URL externo de redirecionamento permitido para a sua aplicação. No exemplo seguinte, redirecionar
https://myexternalurl.com para que não esteja hospedado no mesmo domínio:
GET /.auth/logout?post_logout_redirect_uri=https%3A%2F%2Fmyexternalurl.com
Executar o seguinte comando na Casca de Nuvem Azure:
az webapp auth update --name <app_name> --resource-group <group_name> --allowed-external-redirect-urls

"https://myexternalurl.com"
Preservar fragmentos de URL

Depois de os utilizadores iniciarem sessão na sua aplicação, normalmente querem /wiki/Main_Page#SectionZ ser
redirecionados para a mesma secção da mesma página, como . No entanto, uma vez #SectionZ que os
fragmentos de URL (por exemplo, ) nunca são enviados para o servidor, não são preservados por padrão após o
login OAuth completar e redirecionar de volta para a sua aplicação. Os utilizadores obtêm então uma
experiência sub-óptima quando precisam de navegar novamente para a âncora desejada. Esta limitação aplica-
se a todas as soluções de autenticação do lado do servidor.
Na autenticação do Serviço de Aplicações, pode preservar fragmentos de URL através do login OAuth. Para isso,
defina uma WEBSITE_AUTH_PRESERVE_URL_FRAGMENT true definição de aplicação chamada para . Pode fazê-lo no
portal Azure,ou simplesmente executar o seguinte comando na Casca de Nuvem Azure:
az webapp config appsettings set --name <app_name> --resource-group <group_name> --settings

WEBSITE_AUTH_PRESERVE_URL_FRAGMENT="true"
Aceder às reclamações dos utilizadores
O Serviço de Aplicações transmite as alegações dos utilizadores à sua aplicação utilizando cabeçalhos especiais.
Os pedidos externos não são permitidos definir estes cabeçalhos, por isso só estão presentes se definidos pelo
Serviço de Aplicações. Alguns cabeçalhos de exemplo incluem:
X-MS-CLIENTE-PRINCIPAL-NAME
X-MS-CLIENTE-PRINCIPAL-ID
O código que está escrito em qualquer língua ou enquadramento pode obter a informação de que necessita
destes cabeçalhos. Para ASP.NET 4.6 aplicações, o ClaimsPrincipal é automaticamente definido com os valores
apropriados. ASP.NET Core, no entanto, não fornece um middleware de autenticação que se integre com as
alegações dos utilizadores do App Service. Para uma suposição, consulte
MaximeRouiller.Azure.AppService.EasyAuth.
A sua aplicação também pode obter detalhes /.auth/me adicionais sobre o utilizador autenticado através da
chamada . Os SDKs do servidor de aplicativos móveis fornecem métodos de ajuda para trabalhar com estes
dados. Para mais informações, consulte Como utilizar as aplicações móveis Azure Node.js SDKe Trabalhe com o
servidor de backend .NET SDK para Aplicações Móveis Azure.
Recuperar fichas no código da aplicação

A partir do código do servidor, as fichas específicas do fornecedor são injetadas no cabeçalho do pedido, para
que possa aceder facilmente aos mesmos. A tabela que se segue mostra possíveis nomes de cabeçalho
simbólico:
F O RN EC EDO R N O M ES DE C A B EÇ A L H O
Azure Active Directory X-MS-TOKEN-AAD-ID-TOKEN

X-MS-TOKEN-AAD-ACCESS-TOKEN
X-MS-TOKEN-AAD-EXPIRES-ON
X-MS-TOKEN-AAD-REFRESH-TOKEN
Ficha do Facebook X-MS-TOKEN-FACEBOOK-ACCESS-TOKEN

X-MS-TOKEN-FACEBOOK-EXPIRES-ON
Google X-MS-TOKEN-GOOGLE-ID-TOKEN
X-MS-TOKEN-GOOGLE-ACCESS-TOKEN
X-MS-TOKEN-GOOGLE-EXPIRES-ON
X-MS-TOKEN-GOOGLE-REFRESH-TOKEN
Conta Microsoft X-MS-TOKEN-MICROSOFTACCOUNT-ACCESS-TOKEN

X-MS-TOKEN-MICROSOFTACCOUNT-EXPIRES-ON
X-MS-TOKEN-MICROSOFTACCOUNT-AUTHENTICATION-TOKEN
X-MS-TOKEN-MICROSOFTACCOUNT-REFRESH-TOKEN
Twitter X-MS-TOKEN-TWITTER-ACCESS-TOKEN
X-MS-TOKEN-TWITTER-ACCESS-TOKEN-SECRET
A partir do seu código de cliente (como uma aplicação móvel ou javaScript no navegador), envie um pedido
HTTP GET para /.auth/me . A JSON devolvida tem as fichas específicas do fornecedor.
NOTE
Os tokens de acesso são para aceder aos recursos do fornecedor, pelo que só estão presentes se configurar o seu
fornecedor com um segredo de cliente. Para ver como obter fichas refrescantes, consulte fichas de acesso Refresh.
Atualizar fichas de fornecedor de identidade

Quando o sinal de acesso do seu fornecedor (não o token da sessão)expirar, tem de reautenticar o utilizador
antes de voltar a utilizar esse símbolo. Pode evitar a expiração do GET símbolo /.auth/refresh fazendo uma
chamada para o ponto final da sua aplicação. Quando chamado, o Serviço de Aplicações atualiza
automaticamente as fichas de acesso na loja token para o utilizador autenticado. Os pedidos subsequentes de
fichas pelo código da aplicação obtêm os tokens renovados. No entanto, para que a atualização token funcione,
a loja de fichas deve conter fichas de atualização para o seu fornecedor. A forma de obter fichas de atualização é
documentada por cada fornecedor, mas a seguinte lista é um breve resumo:
Google : Anexar um access_type=offline parâmetro de /.auth/login/google corda de consulta à sua
chamada API. Se utilizar o SDK de Aplicações Móveis, LogicAsync pode adicionar o parâmetro a uma das
sobrecargas (ver Google Refresh Tokens).
Facebook : Não fornece fichas de atualização. As fichas de longa duração expiram em 60 dias (ver Facebook
Expiração e Extensão de Fichas de Acesso).
Twitter : As fichas de acesso não expiram (ver Twitter OAuth FAQ).
Conta Microsoft : Ao configurar as definiçõesde autenticação da conta microsoft, selecione o
wl.offline_access âmbito.
Diretório Ativo Azure : In, https://resources.azure.comfaça os seguintes passos:
1. No topo da página, selecione Ler/Escrever .
2. No navegador esquerdo, navegue para subscrições > <_nome de grupo > > derecursos Os >
<recursos_de recursos_> > fornecedores****Microsoft.Web > sites > <nome de
aplicação_> > authsettings config > .
3. Clique em Editar .
4. Modificar a seguinte propriedade. Substitua _ <__ o id da aplicação>com o ID de aplicação azure
Ative Directory do serviço a que pretende aceder.
"additionalLoginParams": ["response_type=code id_token", "resource=<app_id>"]
5. Clique em Colocar .
Uma vez configurado o seu fornecedor, pode encontrar o token de atualização e o tempo de validade para o
token de acesso na loja de fichas.
Para refrescar o seu sinal de /.auth/refresh acesso a qualquer momento, basta ligar para qualquer idioma. O
seguinte snippet usa jQuery para refrescar as suas fichas de acesso de um cliente JavaScript.
function refreshTokens() {
let refreshUrl = "/.auth/refresh";
$.ajax(refreshUrl) .done(function() {
console.log("Token refresh completed successfully.");
}) .fail(function() {
console.log("Token refresh failed. See application logs for details.");
});
}
Se um utilizador revogar as permissões concedidas /.auth/me à sua 403 Forbidden aplicação, a sua chamada
poderá falhar com uma resposta. Para diagnosticar erros, verifique os registos da sua aplicação para obter
detalhes.
Prolongar período de carência de validade da sessão

A sessão autenticada expira após 8 horas. Após o termo de uma sessão autenticada, existe um período de
carência de 72 horas por defeito. Dentro deste período de carência, é permitido refrescar a sessão com o Serviço
de Aplicações sem reautenticar o utilizador. Pode ligar /.auth/refresh quando o seu token da sessão se tornar
inválido, e não precisa de rastrear a expiração do símbolo. Uma vez que o período de carência de 72 horas é
caducado, o utilizador deve iniciar sessão novamente para obter um token de sessão válido.
Se 72 horas não forem tempo suficiente para si, pode estender esta janela de validade. O alargamento da
expiração por um longo período pode ter implicações significativas na segurança (como quando um token de
autenticação é vazado ou roubado). Por isso, deve deixá-lo no padrão 72 horas ou definir o período de extensão
para o menor valor.
Para estender a janela de validade predefinida, execute o seguinte comando na Cloud Shell.
az webapp auth update --resource-group <group_name> --name <app_name> --token-refresh-extension-hours

<hours>
NOTE
O período de carência aplica-se apenas à sessão autenticada do Serviço de Aplicações, e não aos símbolos dos
fornecedores de identidade. Não existe um período de carência para os tokens do fornecedor expirado.
Limitar o domínio das contas de inscrição

Tanto a Microsoft Account como o Azure Ative Directory permitem-lhe iniciar sessão a partir de vários domínios.
Por exemplo, a Conta Microsoft permite contas outlook.com, _live.com_e hotmail.com. A Azure AD permite
qualquer número de domínios personalizados para as contas de entrada. No entanto, pode querer acelerar os
seus utilizadores diretamente para a contoso.com sua própria página de entrada de anúncios Azure AD (por
exemplo). Para sugerir o nome de domínio das contas de inscrição, siga estes passos.
Em https://resources.azure.com, navegue para subscrições > <_nome de recurso > Recursos Grupos > <de
recursos__nome> > fornecedores > Microsoft.Web > sites > <nome_> > authsettings config > .
Clique em Editar, modifique a seguinte propriedade e, em seguida, clique em Colocar . Certifique-se _ <de__
substituir o nome de domínio>pelo domínio que deseja.
"additionalLoginParams": ["domain_hint=<domain_name>"]
Esta definição adere o parâmetro de domain_hint corda de consulta ao URL de redirecionamento de login.
IMPORTANT
É possível que o cliente domain_hint remova o parâmetro depois de receber o URL de redirecionamento e, em seguida,
iniciar sessão com um domínio diferente. Por isso, embora esta função seja conveniente, não é uma funcionalidade de
segurança.
Autorizar ou negar utilizadores

Embora o Serviço de Aplicações cuide do caso de autorização mais simples (ou seja, rejeitar pedidos não
autenticados), a sua aplicação pode necessitar de um comportamento de autorização mais fino, como limitar o
acesso a apenas um determinado grupo de utilizadores. Em certos casos, é necessário escrever um código de
aplicação personalizado para permitir ou negar o acesso ao utilizador inscrito. Noutros casos, o Serviço de
Aplicações ou o seu fornecedor de identidade poderão ajudar sem exigir alterações de código.
Nível de servidor
Nível de fornecedor de identidade
Nível de candidatura
Nível de servidor (apenas aplicações do Windows)
Para qualquer aplicação do Windows, pode definir o comportamento de autorização do servidor web IIS,
editando o ficheiro Web.config. As aplicações Linux não usam o IIS e não podem ser configuradas através do
Web.config.
1. Navegar para https://<app-name>.scm.azurewebsites.net/DebugConsole
2. No navegador explorador dos seus ficheiros do Serviço de Aplicações, navegue para site/wwwroot. Se
um Web.config não existir, crie-o selecionando + > New File .
3. Selecione o lápis para Web.config para editá-lo. Adicione o seguinte código de configuração e clique em
Guardar . Se web.config já existir, <authorization> basta adicionar o elemento com tudo o que estiver
nele. Adicione as contas que pretende <allow> permitir no elemento.
<?xml version="1.0" encoding="utf-8"?>

<configuration>
<system.web>
<authorization>
<allow users="user1@contoso.com,user2@contoso.com"/>
<deny users="*"/>
</authorization>
</system.web>
</configuration>
Nível de fornecedor de identidade

O fornecedor de identidade pode fornecer uma certa autorização chave-na-mão. Por exemplo:
Para o Azure App Service,pode gerir o acesso a nível empresarial diretamente em Azure AD. Para obter
instruções, consulte Como remover o acesso de um utilizador a uma aplicação.
Para o Google,os projetos google API que pertencem a uma organização podem ser configurados para
permitir o acesso apenas aos utilizadores da sua organização (ver página de suporte o OAuth 2.0 da
Google).
Nível de candidatura
Se algum dos outros níveis não fornecer a autorização de que necessita, ou se a sua plataforma ou fornecedor
de identidade não for suportado, deve escrever código personalizado para autorizar utilizadores com base nas
alegaçõesdo utilizador .
Passos seguintes
Tutorial: Autenticar e autorizar utilizadores de ponta a ponta (Windows) Tutorial: Autenticar e autorizar
utilizadores de ponta a ponta (Linux)
Restrições de acesso ao Serviço de Aplicações
Azure
As restrições de acesso permitem definir uma lista de permitir/negar prioritáriamente que controla o acesso à
rede à sua aplicação. A lista pode incluir endereços IP ou subredes azure rede virtual. Quando há uma ou mais
entradas, há então um implícito "negar tudo" que existe no final da lista.
A capacidade de restrições de acesso funciona com todos os serviços de aplicação hospedados, incluindo;
aplicações web, aplicativos API, aplicativos Linux, aplicações de contentores Linux e Funções.
Quando um pedido é feito na sua aplicação, o endereço FROM é avaliado contra as regras de endereço IP na
sua lista de restrições de acesso. Se o endereço FROM estiver numa subnet configurada com pontos finais de
serviço para microsoft.Web, então a subnet de origem é comparada com as regras de rede virtual na sua lista
de restrições de acesso. Se o endereço não for permitido o acesso com base nas regras da lista, o serviço
responde com um código de estado HTTP 403.
A capacidade de restrições de acesso é implementada nas funções front-end do Serviço de Aplicações, que são
a montante dos anfitriões dos trabalhadores onde o seu código funciona. Por conseguinte, as restrições de
acesso são efetivamente ACLs de rede.
A capacidade de restringir o acesso à sua aplicação web a partir de uma Rede Virtual Azure (VNet) chama-se
pontos finaisde serviço . Os pontos finais do serviço permitem-lhe restringir o acesso a um serviço multi-
inquilino a partir de subredes selecionadas. Deve ser ativado tanto no lado da rede como no serviço com o que
está a ser ativado. Não funciona para restringir o tráfego a apps que estão hospedadas num Ambiente de
Serviço de Aplicações. Se estiver num Ambiente de Serviço de Aplicações, pode controlar o acesso à sua
aplicação com regras de endereço IP.
Adicionar e editar regras de restrição de acesso no portal

Para adicionar uma regra de restrição de acesso à sua aplicação, use o menu para abrirrestrições de acesso à
rede >e clique em Restrições de Acesso Configuradas
A partir do UI de Restrições de Acesso, pode rever a lista de regras de restrição de acesso definidas para a sua
aplicação.
A lista mostrará todas as restrições atuais que estão na sua aplicação. Se tiver uma restrição VNet na sua
aplicação, a tabela mostrará se os pontos finais do serviço estão ativados para microsoft.Web. Quando não
houver restrições definidas na sua aplicação, a sua aplicação estará acessível a partir de qualquer lugar.
Adicionar regras de endereço IP

Pode clicar em [+] Adicionar regra para adicionar uma nova regra de restrição de acesso. Uma vez
adicionado uma regra, ela vai tornar-se eficaz imediatamente. As regras são aplicadas por ordem prioritária, a
partir do número mais baixo e a subir. Há uma negação implícita de tudo o que está em vigor quando se
adiciona uma única regra.
Ao criar uma regra, deve selecionar permitir/negar e também o tipo de regra. Também é obrigado a fornecer o
valor prioritário e aquilo a que está a restringir o acesso. Pode, opcionalmente, adicionar um nome e descrição
opcionalmente à regra.
Para definir uma regra baseada em endereçoIP, selecione um tipo de IPv4 ou IPv6. A notação do endereço IP
deve ser especificada na notação CIDR para os endereços IPv4 e IPv6. Para especificar um endereço exato, pode
utilizar algo como 1.2.3.4/32 onde os quatro primeiros octetos representam o seu endereço IP e /32 é a
máscara. A notação cidr IPv4 para todos os endereços é 0.0.0.0/0. Para saber mais sobre a notação do CIDR,
pode ler O Encaminhamento Inter-Domínio Sem Classe.

Os pontos finais do serviço permitem-lhe restringir o acesso a subredes de rede virtual Azure selecionadas.
Para restringir o acesso a uma subnetespecífica específica, crie uma regra de restrição com um tipo de Rede
Virtual. Pode escolher a subscrição, VNet e subnet que deseja permitir ou negar o acesso. Se os pontos finais do
serviço ainda não estiverem ativados com a Microsoft.Web para a sub-rede que selecionou, será
automaticamente ativado para si, a menos que verifique a caixa pedindo para não o fazer. A situação em que o
desejaria ativar na aplicação, mas não a subnet, está em grande parte relacionada com se tiver permissões para
ativar pontos finais de serviço na subnet ou não. Se precisar de alguém para ativar os pontos finais do serviço
na subnet, pode verificar a caixa e configurar a sua aplicação para pontos finais de serviço, antecipando que
seja ativada mais tarde na subnet.
Os pontos finais do serviço não podem ser utilizados para restringir o acesso a apps que funcionam num
Ambiente de Serviço de Aplicações. Quando a sua aplicação estiver num Ambiente de Serviço de Aplicações,
pode controlar o acesso à sua aplicação com regras de acesso IP.
Com pontos finais de serviço, pode configurar a sua aplicação com Gateways de Aplicação ou outros
dispositivos WAF. Também pode configurar aplicações de vários níveis com backends seguros. Para mais
detalhes sobre algumas das possibilidades, leia as funcionalidades de Networking e o Serviço de Aplicações e a
integração do Gateway de Aplicações com pontos finaisde serviço.
Gestão das regras de restrição de acesso

Pode clicar em qualquer linha para editar uma regra de restrição de acesso existente. As edificações estão em
vigor imediatamente, incluindo alterações na ordem de encomendas prioritárias.
Ao editar uma regra, não pode alterar o tipo entre uma regra de endereço IP e uma regra de Rede Virtual.
Para eliminar uma regra, clique no ... na sua regra e, em seguida, clique em Remover .
Bloquear um único endereço IP
Ao adicionar a sua primeira regra de restrição IP, o serviço adicionará uma regra de Negação explícita com
uma prioridade de 2147483647. Na prática, a regra explícita de Negação será executada na última regra e
bloqueará o acesso a qualquer endereço IP que não seja explicitamente permitido usando uma regra de
permitir.
Para o cenário em que os utilizadores pretendam bloquear explicitamente um único endereço IP ou bloco de
endereçoIP, mas permitir o acesso de tudo o resto, é necessário adicionar uma regra de permitir todas
explícitas.
Site SCM
Além de poder controlar o acesso à sua aplicação, também pode restringir o acesso ao site SCM utilizado pela
sua aplicação. O site scm é o ponto final de implantação da web e também a consola Kudu. Pode atribuir
separadamente restrições de acesso ao site scm da aplicação ou utilizar o mesmo conjunto tanto para a app
como para o site scm. Quando verifica a caixa para ter as mesmas restrições que a sua aplicação, tudo é
apagado. Se desverificar a caixa, são aplicadas as definições que tiver anteriormente no site scm.
Manipulação programática das regras de restrição de acesso
A Azure CLI e a Azure PowerShell têm suporte para a edição de restrições de acesso. Exemplo de adição de uma
restrição de acesso utilizando o Azure CLI:
az webapp config access-restriction add --resource-group ResourceGroup --name AppName \

--rule-name 'IP example rule' --action Allow --ip-address 122.133.144.0/24 --priority 100
Exemplo de adicionar uma restrição de acesso utilizando o Azure PowerShell:
Add-AzWebAppAccessRestrictionRule -ResourceGroupName "ResourceGroup" -WebAppName "AppName"

-Name "Ip example rule" -Priority 100 -Action Allow -IpAddress 122.133.144.0/24
Os valores também podem ser definidos manualmente com uma operação Azure REST API PUT na
configuração da aplicação em Resource Manager ou utilizando um modelo de Gestor de Recursos Azure. Como
exemplo, pode utilizar resources.azure.com e editar o bloco ipSecurityRestrictions para adicionar o JSON
necessário.
A localização desta informação no Gestor de Recursos é:
management.azure.com/subscriptions/ ID /recursosDedados/grupos
derecursos/fornecedores/Microsoft.Web/sites/****web app name /config/web?api-version=2018-02-
01subscription ID
A sintaxe jSON para o exemplo anterior é:
{
"properties": {
"ipSecurityRestrictions": [
{
"ipAddress": "122.133.144.0/24",
"action": "Allow",
"priority": 100,
"name": "IP example rule"
}
]
}
}
Restrições de acesso às Funções Azure

As restrições de acesso também estão disponíveis para aplicações de funções com a mesma funcionalidade que
os planos do App Service. Permitir restrições de acesso irá desativar o editor de código do portal para
quaisquer IPs não autorizados.
Passos seguintes
Restrições de acesso às Funções Azure
Integração de Gateway de aplicação com pontos finais de serviço
Como utilizar identidades geridas para o Serviço de
Aplicações e Funções Azure
Este tópico mostra-lhe como criar uma identidade gerida para aplicações de App Service e Azure Functions e
como usá-lo para aceder a outros recursos.
IMPORTANT
As identidades geridas para o Serviço de Aplicações e Funções Azure não se comportarão como esperado se a sua
aplicação for migrada através de subscrições/inquilinos. A aplicação necessita de obter uma nova identidade, que é feita
desativando e reativando a funcionalidade. Veja a remoção de uma identidade abaixo. Os recursos a jusante também
precisam de ter políticas de acesso atualizadas para utilizar a nova identidade.
Uma identidade gerida do Azure Ative Directory (Azure AD) permite que a sua aplicação aceda facilmente a
outros recursos protegidos por AD Azure, como o Azure Key Vault. A identidade é gerida pela plataforma Azure
e não o obriga a fornecer ou rodar quaisquer segredos. Para saber mais sobre identidades geridas em Azure AD,
consulte identidades geridas para recursos Azure.
A sua aplicação pode ser concedida a dois tipos de identidades:
Uma identidade atribuída ao sistema está ligada à sua aplicação e é eliminada se a sua aplicação for
eliminada. Uma aplicação só pode ter uma identidade atribuída ao sistema.
Uma identidade atribuída ao utilizador é um recurso Azure autónomo que pode ser atribuído à sua
aplicação. Uma aplicação pode ter várias identidades atribuídas ao utilizador.
Adicionar uma identidade atribuída ao sistema

A criação de uma app com uma identidade atribuída ao sistema requer uma propriedade adicional a ser definida
na aplicação.
Utilizar o portal do Azure
Para configurar uma identidade gerida no portal, irá primeiro criar uma aplicação normal e depois ativar a
funcionalidade.
1. Crie uma aplicação no portal como normalmente faria. Navegue até ele no portal.
2. Se utilizar uma aplicação de função, navegue para as funcionalidades da Plataforma. Para outros
tipos de aplicativos, desloque-se até ao grupo Definições na navegação à esquerda.
3. Selecione identidade .
4. Dentro do separador Designado sistema, altere o Estado para ligar . Clique em Guardar .
NOTE
Para encontrar a identidade gerida para a sua web ou app slot no portal Azure, aceda à secção de definições do Utilizador
sob aplicações da Enterprise.
Com a CLI do Azure

Para configurar uma identidade gerida utilizando o CLI Azure, terá de utilizar o az webapp identity assign
comando contra uma aplicação existente. Tem três opções para executar os exemplos nesta secção:
Utilize a Azure Cloud Shell a partir do portal Azure.
Utilize o Azure Cloud Shell incorporado através do botão "Try It", localizado no canto superior direito de cada
bloco de código abaixo.
Instale a versão mais recente do Azure CLI (2.0.31 ou posterior) se preferir utilizar uma consola CLI local.
Os seguintes passos irão acompanhá-lo através da criação de uma aplicação web e atribuindo-lhe uma
identidade usando o CLI:
1. Se estiver a utilizar a CLI do Azure numa consola local, primeiro inicie sessão no Azure com az login.
Utilize uma conta associada à subscrição Azure sob a qual pretende implementar a aplicação:
az login
2. Crie uma aplicação web utilizando o CLI. Para obter mais exemplos de como utilizar o CLI com o Serviço
de Aplicações, consulte as amostras do Serviço de Aplicações CLI:
az group create --name myResourceGroup --location westus

az appservice plan create --name myPlan --resource-group myResourceGroup --sku S1
az webapp create --name myApp --resource-group myResourceGroup --plan myPlan
3. Executar o identity assign comando para criar a identidade para esta aplicação:
az webapp identity assign --name myApp --resource-group myResourceGroup

NOTE
Os seguintes passos irão acompanhá-lo através da criação de uma app e atribuindo-lhe uma identidade usando
a Azure PowerShell. As instruções para a criação de uma aplicação web e de uma aplicação de função são
diferentes.
Usando a Azure PowerShell para uma aplicação web
1. Se necessário, instale o Azure PowerShell utilizando as instruções encontradas no guia Azure
PowerShelle, em seguida, corra Login-AzAccount para criar uma ligação com a Azure.
2. Crie uma aplicação web utilizando a Azure PowerShell. Para obter mais exemplos de como utilizar o
Azure PowerShell com o Serviço de Aplicações, consulte as amostras powerShell do Serviço de
Aplicações:

New-AzResourceGroup -Name $resourceGroupName -Location $location

New-AzAppServicePlan -Name $webappname -Location $location -ResourceGroupName $resourceGroupName -
Tier Free
# Create a web app.

New-AzWebApp -Name $webappname -Location $location -AppServicePlan $webappname -ResourceGroupName
$resourceGroupName
3. Executar o Set-AzWebApp -AssignIdentity comando para criar a identidade para esta aplicação:
Set-AzWebApp -AssignIdentity $true -Name $webappname -ResourceGroupName $resourceGroupName
Usando a Azure PowerShell para uma aplicação de função

2. Crie uma aplicação de função utilizando o Azure PowerShell. Para obter mais exemplos de como utilizar a
Azure PowerShell com Funções Azure, consulte a referência Az.Functions:

# Create a storage account.

New-AzStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -SkuName $sku
# Create a function app with a system-assigned identity.

New-AzFunctionApp -Name $functionAppName -ResourceGroupName $resourceGroupName -Location $location -
StorageAccountName $storageAccountName -Runtime $runtime -IdentityType SystemAssigned
Também pode atualizar uma aplicação de função existente Update-AzFunctionApp utilizando.

Usando um modelo de gestor de recursos Azure
Um modelo de Gestor de Recursos Azure pode ser usado para automatizar a implementação dos seus recursos
Azure. Para saber mais sobre a implementação do Serviço de Aplicações e Funções, consulte automatizar a
implementação de recursos no Serviço de Aplicações e Automatizar a implementação de recursos em Funções
Azure.
Qualquer recurso de tipo Microsoft.Web/sites pode ser criado com uma identidade, incluindo a seguinte
propriedade na definição de recurso:
"identity": {
}
NOTE
Uma aplicação pode ter identidades atribuídas ao sistema e atribuídas ao mesmo tempo. Neste caso, a type
propriedade seria SystemAssigned,UserAssigned
A adição do tipo atribuído ao sistema diz ao Azure para criar e gerir a identidade para a sua aplicação.
Por exemplo, uma aplicação web pode parecer o seguinte:
{
"apiVersion": "2016-08-01",
"name": "[variables('appName')]",
"location": "[resourceGroup().location]",
"identity": {
},
"properties": {
"serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
"hostingEnvironment": "",
"clientAffinityEnabled": false,
"alwaysOn": true
},
"dependsOn": [
"[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]"
]
}
Quando o site é criado, tem as seguintes propriedades adicionais:
"identity": {
"type": "SystemAssigned",
"tenantId": "<TENANTID>",
"principalId": "<PRINCIPALID>"
}
A propriedade do inquilinoId identifica a que Azure AD inquilino a identidade pertence. O directorid é um

identificador único para a nova identidade da aplicação. Dentro da Azure AD, o responsável pelo serviço tem o
mesmo nome que deu ao seu Serviço de Aplicações ou à instância Azure Functions.
Adicionar uma identidade atribuída ao utilizador

A criação de uma aplicação com uma identidade atribuída ao utilizador requer que crie a identidade e adicione o
seu identificador de recursos à sua app config.
Utilizar o portal do Azure
Primeiro, terá de criar um recurso de identidade atribuído ao utilizador.
1. Criar um recurso de identidade gerido atribuído pelo utilizador de acordo com estas instruções.
2. Crie uma aplicação no portal como normalmente faria. Navegue até ele no portal.
3. Se utilizar uma aplicação de função, navegue para as funcionalidades da Plataforma. Para outros
tipos de aplicativos, desloque-se até ao grupo Definições na navegação à esquerda.
4. Selecione identidade .
5. Dentro do separador Utilizador atribuído, clique em Adicionar .
6. Procure a identidade que criou anteriormente e selecione-a. Clique em Adicionar .
NOTE
Os seguintes passos irão acompanhá-lo através da criação de uma app e atribuindo-lhe uma identidade usando
a Azure PowerShell.
NOTE
A versão atual dos comandos Azure PowerShell para o Azure App Service não suporta identidades atribuídas ao utilizador.
As instruções abaixo são para Funções Azure.

2. Crie uma aplicação de função utilizando o Azure PowerShell. Para obter mais exemplos de como utilizar a
Azure PowerShell com Funções Azure, consulte a referência Az.Functions. O script abaixo também utiliza
New-AzUserAssignedIdentity o qual deve ser instalado separadamente de acordo com a Criação, lista ou
eliminação de uma identidade gerida atribuída pelo utilizador utilizando a Azure PowerShell.
# Create a storage account.

New-AzStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -SkuName $sku
# Create a user-assigned identity. This requires installation of the "Az.ManagedServiceIdentity"

module.
$userAssignedIdentity = New-AzUserAssignedIdentity -Name $userAssignedIdentityName -ResourceGroupName
$resourceGroupName
# Create a function app with a user-assigned identity.

New-AzFunctionApp -Name $functionAppName -ResourceGroupName $resourceGroupName -Location $location -
StorageAccountName $storageAccountName -Runtime $runtime -IdentityType UserAssigned -IdentityId
$userAssignedIdentity.Id
Também pode atualizar uma aplicação de função existente Update-AzFunctionApp utilizando.

Usando um modelo de gestor de recursos Azure
Um modelo de Gestor de Recursos Azure pode ser usado para automatizar a implementação dos seus recursos
Azure. Para saber mais sobre a implementação do Serviço de Aplicações e Funções, consulte automatizar a
implementação de recursos no Serviço de Aplicações e Automatizar a implementação de recursos em Funções
Azure.
Qualquer recurso do tipo Microsoft.Web/sites pode ser criado com uma identidade, incluindo o seguinte bloco
na definição de recurso, substituindo-o pelo <RESOURCEID> ID de recurso da identidade pretendda:
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"<RESOURCEID>": {}
}
}
NOTE
Uma aplicação pode ter identidades atribuídas ao sistema e atribuídas ao mesmo tempo. Neste caso, a type
propriedade seria SystemAssigned,UserAssigned
A adição do tipo atribuído ao utilizador diz ao Azure para utilizar a identidade atribuída ao utilizador
especificada para a sua aplicação.
Por exemplo, uma aplicação web pode parecer o seguinte:
{
"apiVersion": "2016-08-01",
"location": "[resourceGroup().location]",
"identity": {
"[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', variables('identityName'))]":
{}
}
},
"properties": {
"serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
"hostingEnvironment": "",
"clientAffinityEnabled": false,
"alwaysOn": true
},
"dependsOn": [
"[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
"[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', variables('identityName'))]"
]
}
Quando o site é criado, tem as seguintes propriedades adicionais:
"identity": {
"<RESOURCEID>": {
"principalId": "<PRINCIPALID>",
"clientId": "<CLIENTID>"
}
}
}
O directorid é um identificador único para a identidade que é usada para a administração da AD Azure. O
clientId é um identificador único para a nova identidade da aplicação que é usada para especificar qual
identidade usar durante chamadas de tempo de execução.
Obter fichas para recursos Azure

Uma aplicação pode usar a sua identidade gerida para obter fichas para aceder a outros recursos protegidos
pela Azure AD, como o Azure Key Vault. Estes tokens representam a aplicação que acede ao recurso, e não
qualquer utilizador específico da aplicação.
Pode ser necessário configurar o recurso-alvo para permitir o acesso a partir da sua aplicação. Por exemplo, se
você solicitar um token para aceder ao Key Vault, você precisa ter certeza de que adicionou uma política de
acesso que inclui a identidade da sua aplicação. Caso contrário, as suas chamadas para Key Vault serão
rejeitadas, mesmo que incluam o símbolo. Para saber mais sobre quais os recursos que suportam tokens do
Azure Ative Directory, consulte os serviços Azure que suportam a autenticação AD da Azure.
IMPORTANT
Os serviços back-end para identidades geridas mantêm uma cache por recurso URI durante cerca de 8 horas. Se atualizar
a política de acesso de um determinado recurso alvo e recuperar imediatamente um símbolo para esse recurso, poderá
continuar a obter um token em cache com permissões desatualizadas até que esse token expire. Não há como forçar uma
atualização simbólica.
Existe um protocolo REST simples para obter um token no Serviço de Aplicações e Funções Azure. Isto pode ser
usado para todas as aplicações e idiomas. Para .NET e Java, o Azure SDK fornece uma abstração sobre este
protocolo e facilita uma experiência de desenvolvimento local.
Utilização do protocolo REST
Uma aplicação com uma identidade gerida tem duas variáveis ambientais definidas:
IDENTITY_ENDPOINT - a URL para o serviço de fichas locais.
IDENTITY_HEADER - um cabeçalho usado para ajudar a mitigar os ataques de falsificação de pedidos do lado
do servidor (SSRF). O valor é rodado pela plataforma.
O IDENTITY_ENDPOINT é um URL local a partir do qual a sua aplicação pode solicitar tokens. Para obter um
token para um recurso, faça um pedido HTTP GET para este ponto final, incluindo os seguintes parâmetros:
N O M E DO PA RÂ M ET RO EM DESC RIP T IO N
recurso Consulta O recurso AZURE AD URI do recurso

para o qual deve ser obtido um
símbolo. Este pode ser um dos
serviços Azure que suportam a
autenticação AD AZure ou qualquer
outro recurso URI.
api-version Consulta A versão da API simbólica a ser

utilizada. Por favor, use "2019-08-01"
ou mais tarde.
CABEÇALHO DE IDENTIDADE X Cabeçalho O valor da variável ambiente

IDENTITY_HEADER. Este cabeçalho é
usado para ajudar a atenuar os
ataques de falsificação de pedidos do
servidor (SSRF).
client_id Consulta (Opcional) A identificação do cliente

da identidade atribuída ao utilizador
a ser usada. Não pode ser utilizado
num pedido que principal_id
mi_res_id inclua, ou object_id .
Se todos os parâmetros de
identificação client_id
principal_id (, object_id , , e )
mi_res_id forem omitidos, a
identidade atribuída ao sistema é
utilizada.
N O M E DO PA RÂ M ET RO EM DESC RIP T IO N
principal_id Consulta (Opcional) A identificação principal da

identidade atribuída ao utilizador a
ser utilizada. object_id é um
pseudónimo que pode ser usado em
vez disso. Não pode ser usado num
pedido que inclua client_id, mi_res_id
ou object_id. Se todos os parâmetros
de identificação client_id
utilizada.
mi_res_id Consulta (Opcional) O ID de recurso Azure da

identidade atribuída ao utilizador a
ser utilizado. Não pode ser utilizado
num pedido que principal_id
client_id inclua, ou object_id .
Se todos os parâmetros de
identificação client_id
utilizada.
IMPORTANT
Se estiver a tentar obter fichas para identidades atribuídas ao utilizador, deve incluir uma das propriedades opcionais. Caso
contrário, o serviço de token tentará obter um símbolo para uma identidade atribuída ao sistema, que pode ou não existir.
Uma resposta bem sucedida de 200 OK inclui um corpo JSON com as seguintes propriedades:
N O M E DA P RO P RIEDA DE DESC RIP T IO N
access_token O sinal de acesso solicitado. O serviço web de chamada

pode usar este token para autenticar o serviço web
recetor.
client_id A identificação do cliente da identidade que foi usada.
expires_on O tempo de tempo quando a ficha de acesso expira. A

data é representada como o número de segundos de
"1970-01-01T0:0Z UTC" (corresponde à reivindicação do
exp token).
not_before O período de tempo quando o token de acesso entra em

vigor, e pode ser aceite. A data é representada como o
número de segundos de "1970-01-01T0:0Z UTC"
(corresponde à reivindicação do nbf token).
recurso O recurso para o token de acesso foi solicitado, que

corresponde ao resource parâmetro de cadeia de
consulta do pedido.
N O M E DA P RO P RIEDA DE DESC RIP T IO N
token_type Indica o valor do tipo símbolo. O único tipo que a Azure

AD suporta é o FBearer. Para obter mais informações
sobre fichas ao portador, consulte o Quadro de
Autorização OAuth 2.0: Utilização do Token ao portador
(RFC 6750).
Esta resposta é a mesma que a resposta para o pedido de acesso ao serviço da Azure AD.
NOTE
Uma versão mais antiga deste protocolo, utilizando a versão API "2017-09-01", utilizou o secret cabeçalho em vez de
X-IDENTITY-HEADER e só aceitou a clientid propriedade para o utilizador atribuído. Também devolveu o expires_on
em formato de timetamp. MSI_ENDPOINT pode ser usado como pseudónimo para IDENTITY_ENDPOINT, e MSI_SECRET
pode ser usado como pseudónimo para IDENTITY_HEADER.
Exemplos de protocolo REST

Um pedido de exemplo pode parecer o seguinte:
GET /MSI/token?resource=https://vault.azure.net&api-version=2019-08-01 HTTP/1.1

Host: localhost:4141
X-IDENTITY-HEADER: 853b9a84-5bfa-4b22-a3f3-0b9a43d9ad8a
E uma resposta de amostra pode parecer o seguinte:
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJ0eXAi…",
"expires_on": "1586984735",
"resource": "https://vault.azure.net",
"token_type": "Bearer",
"client_id": "5E29463D-71DA-4FE0-8E69-999B57DB23B0"
}
Exemplos de código
.NET
JavaScript
Python
PowerShell
TIP
Para idiomas .NET, também pode utilizar microsoft.Azure.Services.AppAuthentication em vez de elaborar este pedido por si
mesmo.
private readonly HttpClient _client;
// ...
public async Task<HttpResponseMessage> GetToken(string resource) {
var request = new HttpRequestMessage(HttpMethod.Get,
String.Format("{0}/?resource={1}&api-version=2019-08-01",
Environment.GetEnvironmentVariable("IDENTITY_ENDPOINT"), resource));
request.Headers.Add("X-IDENTITY-HEADER", Environment.GetEnvironmentVariable("IDENTITY_HEADER"));
return await _client.SendAsync(request);
}
Utilização da biblioteca Microsoft.Azure.Services.AppAuthentication para .NET

Para aplicações e funções .NET, a forma mais simples de trabalhar com uma identidade gerida é através do
pacote Microsoft.Azure.Services.AppAuthentication. Esta biblioteca também lhe permitirá testar o seu código
localmente na sua máquina de desenvolvimento, utilizando a sua conta de utilizador a partir do Visual Studio,
do Azure CLIou da Autenticação Integrada do Diretório Ativo. Para obter mais informações sobre as opções de
desenvolvimento local com esta biblioteca, consulte a [referência Microsoft.Azure.Services.AppAuthentication].
Esta secção mostra-lhe como começar com a biblioteca no seu código.
1. Adicione referências ao Microsoft.Azure.Services.AppAuthentication e quaisquer outros pacotes NuGet
necessários à sua aplicação. O exemplo abaixo também utiliza microsoft.Azure.KeyVault.
2. Adicione o seguinte código à sua aplicação, modificando para direcionar o recurso correto. Este exemplo
mostra duas formas de trabalhar com o Azure Key Vault:
using Microsoft.Azure.Services.AppAuthentication;
using Microsoft.Azure.KeyVault;
// ...
var azureServiceTokenProvider = new AzureServiceTokenProvider();
string accessToken = await azureServiceTokenProvider.GetAccessTokenAsync("https://vault.azure.net");
// OR
var kv = new KeyVaultClient(new
KeyVaultClient.AuthenticationCallback(azureServiceTokenProvider.KeyVaultTokenCallback));
Para saber mais sobre microsoft.Azure.Services.AppAuthentication e as operações que expõe, consulte a

[referência Microsoft.Azure.Services.AppAuthentication] e o Serviço de Aplicações e KeyVault com amostra MSI
.NET.
Usando o Azure SDK para Java
Para aplicações e funções java, a forma mais simples de trabalhar com uma identidade gerida é através do Azure
SDK para Java. Esta secção mostra-lhe como começar com a biblioteca no seu código.
1. Adicione uma referência à biblioteca Azure SDK. Para os projetos maven, você pode adicionar este corte à
dependencies secção do arquivo POM do projeto:
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>azure</artifactId>
<version>1.23.0</version>
</dependency>
2. Utilize o AppServiceMSICredentials objeto para autenticação. Este exemplo mostra como este mecanismo
pode ser usado para trabalhar com o Cofre da Chave Azure:
import com.microsoft.azure.AzureEnvironment;
import com.microsoft.azure.management.Azure;
import com.microsoft.azure.management.keyvault.Vault
//...
Azure azure = Azure.authenticate(new AppServiceMSICredentials(AzureEnvironment.AZURE))
.withSubscription(subscriptionId);
Vault myKeyVault = azure.vaults().getByResourceGroup(resourceGroup, keyvaultName);
Remover uma identidade

Uma identidade atribuída ao sistema pode ser removida desativando a funcionalidade utilizando o portal,
PowerShell ou CLI da mesma forma que foi criada. As identidades atribuídas ao utilizador podem ser removidas
individualmente. Para remover todas as identidades, desa um tipo de identidade para "Nenhum".
A remoção de uma identidade atribuída ao sistema desta forma também a eliminará do Azure AD. As
identidades atribuídas ao sistema também são automaticamente removidas do Azure AD quando o recurso da
aplicação é eliminado.
Para remover todas as identidades num modelo ARM:
"identity": {
"type": "None"
}
Para remover todas as identidades em Azure PowerShell (apenas funções Azure):
# Update an existing function app to have IdentityType "None".

Update-AzFunctionApp -Name $functionAppName -ResourceGroupName $resourceGroupName -IdentityType None
NOTE
Há também uma configuração de aplicação que pode ser definida, WEBSITE_DISABLE_MSI, que apenas desativa o serviço
de token local. No entanto, deixa a identidade no lugar, e a ferramenta ainda mostrará a identidade gerida como "on" ou
"ativada". Como resultado, a utilização desta definição não é recomendada.
Passos seguintes
Access SQL Database de forma segura usando uma identidade gerida
Utilize referências chave vault para serviço de
aplicações e funções azure
Este tópico mostra-lhe como trabalhar com segredos do Cofre de Chaves Azure na sua aplicação App Service ou
Azure Functions sem exigir alterações de código. Azure Key Vault é um serviço que fornece gestão centralizada de
segredos, com total controlo sobre políticas de acesso e histórico de auditoria.
Concedendo o acesso da sua aplicação ao Key Vault

Para ler segredos do Key Vault, precisa de ter um cofre criado e dar permissão à sua aplicação para aceder ao
mesmo.
1. Crie um cofre chave seguindo o quickstart do Key Vault.
2. Crie uma identidade gerida atribuída ao sistema para a sua aplicação.
NOTE
Atualmente, as referências chave vault apenas suportam identidades geridas atribuídas pelo sistema. As identidades
atribuídas ao utilizador não podem ser utilizadas.
3. Crie uma política de acesso no Key Vault para a identidade de aplicação que criou anteriormente. Ative a
permissão secreta "Obter" nesta política. Não configure a "aplicação applicationId autorizada" ou as
definições, uma vez que esta não é compatível com uma identidade gerida.
NOTE
As referências key Vault não são atualmente capazes de resolver segredos armazenados num cofre chave com
restriçõesde rede .
Sintaxe de referência
Uma referência chave vault @Microsoft.KeyVault({referenceString}) é {referenceString} do formulário, onde é
substituído por uma das seguintes opções:
C A DEIA DE REF ERÊN C IA DESC RIÇ Ã O
SecretUri=secretUri O SecretUri deve ser o uri de um segredo em Key Vault,

incluindo uma versão, por
exemplo,https://myvault.vault.azure.net/secrets/mysecret/ec9
6f02080254f109c51a1f14cdb1931
Nome do_cofre= nome do cofre;_ SecretName=SecretName; O Nome do Cofre deve ser o nome do seu recurso Key
SecretVersion=secretVersion Vault. O Nome Secreto deve ser o nome do segredo alvo. A
Versão Secreta deve ser a versão do segredo a usar.
Por exemplo, uma referência completa com versão seria como o seguinte:
@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb19
31)
Em alternativa:
@Microsoft.KeyVault(VaultName=myvault;SecretName=mysecret;SecretVersion=ec96f02080254f109c51a1f14cdb1931)
Definições de aplicação de origem do cofre de chaves

As referências do Cofre chave podem ser usadas como valores para Definições de Aplicação,permitindo-lhe
guardar segredos no Cofre chave em vez do config do site. As definições de aplicação são encriptadas de forma
segura em repouso, mas se precisar de capacidades de gestão secretas, devem entrar no Cofre chave.
Para utilizar uma referência do Cofre chave para uma definição de aplicação, defina a referência como o valor da
definição. A sua aplicação pode fazer referência ao segredo através da sua chave como normal. Não são
necessárias alterações de código.
TIP
A maioria das definições de aplicação utilizando referências chave vault deve ser marcada como configurações de slot, uma
vez que deve ter cofres separados para cada ambiente.
Implementação do Azure Resource Manager

Ao automatizar as implementações de recursos através dos modelos do Gestor de Recursos Do Azure, poderá ser
necessário sequenciar as suas dependências de uma determinada ordem para que esta funcionalidade funcione.
De notar que terá de definir as definições da sua siteConfig aplicação como recurso próprio, em vez de utilizar
uma propriedade na definição do site. Isto porque o site precisa de ser definido primeiro para que a identidade
atribuída ao sistema seja criada com ele e possa ser usada na política de acesso.
Um modelo de psuedo exemplo para uma aplicação de função pode parecer o seguinte:
{
//...
"resources": [
{
"type": "Microsoft.Storage/storageAccounts",
"name": "[variables('storageAccountName')]",
//...
},
{
"type": "Microsoft.Insights/components",
"name": "[variables('appInsightsName')]",
//...
},
{
"name": "[variables('functionAppName')]",
"identity": {
},
//...
"resources": [
{
"type": "config",
"name": "appsettings",
//...
"dependsOn": [
"[resourceId('Microsoft.Web/sites', variables('functionAppName'))]",
"[resourceId('Microsoft.KeyVault/vaults/', variables('keyVaultName'))]",
"[resourceId('Microsoft.KeyVault/vaults/secrets', variables('keyVaultName'),
variables('storageConnectionStringName'))]",
"[resourceId('Microsoft.KeyVault/vaults/secrets', variables('keyVaultName'),
variables('appInsightsKeyName'))]"
],
"properties": {
"AzureWebJobsStorage": "[concat('@Microsoft.KeyVault(SecretUri=',
reference(variables('storageConnectionStringResourceId')).secretUriWithVersion, ')')]",
"WEBSITE_CONTENTAZUREFILECONNECTIONSTRING": "
[concat('@Microsoft.KeyVault(SecretUri=',
reference(variables('storageConnectionStringResourceId')).secretUriWithVersion, ')')]",
"APPINSIGHTS_INSTRUMENTATIONKEY": "[concat('@Microsoft.KeyVault(SecretUri=',
reference(variables('appInsightsKeyResourceId')).secretUriWithVersion, ')')]",
"WEBSITE_ENABLE_SYNC_UPDATE_SITE": "true"
//...
}
},
{
"type": "sourcecontrols",
"name": "web",
//...
"dependsOn": [
"[resourceId('Microsoft.Web/sites/config', variables('functionAppName'),
'appsettings')]"
],
}
]
},
{
"type": "Microsoft.KeyVault/vaults",
"name": "[variables('keyVaultName')]",
//...
"dependsOn": [
"[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
],
"properties": {
//...
"accessPolicies": [
{
"tenantId": "[reference(concat('Microsoft.Web/sites/', variables('functionAppName'),
'/providers/Microsoft.ManagedIdentity/Identities/default'), '2015-08-31-PREVIEW').tenantId]",
"objectId": "[reference(concat('Microsoft.Web/sites/', variables('functionAppName'),
'/providers/Microsoft.ManagedIdentity/Identities/default'), '2015-08-31-PREVIEW').principalId]",
"permissions": {
"secrets": [ "get" ]
}
}
]
},
"resources": [
{
"type": "secrets",
"name": "[variables('storageConnectionStringName')]",
//...
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]"
],
"properties": {
"value": "[concat('DefaultEndpointsProtocol=https;AccountName=',
variables('storageAccountName'), ';AccountKey=', listKeys(variables('storageAccountResourceId'),'2015-05-01-
preview').key1)]"
}
},
{
"type": "secrets",
"name": "[variables('appInsightsKeyName')]",
"name": "[variables('appInsightsKeyName')]",
//...
"dependsOn": [
"[resourceId('Microsoft.Insights/components', variables('appInsightsName'))]"
],
"properties": {
"value": "[reference(resourceId('microsoft.insights/components/',
variables('appInsightsName')), '2015-05-01').InstrumentationKey]"
}
}
]
}
]
}
NOTE
Neste exemplo, a implementação do controlo de origem depende das definições de aplicação. Normalmente, este
comportamento é normalmente inseguro, uma vez que a atualização de definição de aplicações se comporta
assincronicamente. No entanto, como WEBSITE_ENABLE_SYNC_UPDATE_SITE incluímos a definição de aplicação, a
atualização é sincronizada. Isto significa que a implementação do controlo de fonte só começará depois de as definições de
aplicação terem sido totalmente atualizadas.
Referências do cofre de resolução de problemas

Se uma referência não for resolvida corretamente, o valor de referência será utilizado. Isto significa que, para as
definições de aplicação, seria criada uma variável ambiental cujo valor tem a @Microsoft.KeyVault(...) sintaxe.
Isto pode fazer com que a aplicação lance erros, uma vez que estava à espera de um segredo de uma
determinada estrutura.
Mais comummente, isto deve-se a uma configuração errada da política de acesso do Cofre Chave. No entanto,
também pode ser devido a um segredo que já não existe ou a um erro de sintaxe na própria referência.
Se a sintaxe estiver correta, pode visualizar outras causas de erro verificando o estado de resolução atual no
portal. Navegue para Definições de Aplicação e selecione "Editar" para a referência em questão. Abaixo da
configuração de definição, deve ver informações de estado, incluindo quaisquer erros. A ausência destes implica
que a sintaxe de referência é inválida.
Também pode usar um dos detetores incorporados para obter informações adicionais.
Utilização do detetor para o Serviço de Aplicações
1. No portal, navegue para a sua aplicação.
2. Selecione Diagnosticar e resolver problemas .
3. Escolha disponibilidade e desempenho e selecione web app para baixo.
4. Encontre definições de aplicação do cofre chave E clique em mais informações .
Utilização do detetor para funções azure
1. No portal, navegue para a sua aplicação.
2. Navegue para as funcionalidades da Plataforma.
3. Selecione Diagnosticar e resolver problemas .
4. Escolha disponibilidade e desempenho e selecione app 'Função' para baixo ou erros de repor te.
5. Clique em Definições de aplicação do cofre de chaves Diagnósticos.
Utilize um certificado TLS/SSL no seu código no
No seu código de aplicação, pode aceder aos certificados públicos ou privados que adiciona ao Serviço de
Aplicações. O seu código de aplicação pode funcionar como cliente e aceder a um serviço externo que requer a
autenticação do certificado, ou pode ter de executar tarefas criptográficas. Este guia de como fazer mostra como
utilizar certificados públicos ou privados no seu código de candidatura.
Esta abordagem à utilização de certificados no seu código utiliza a funcionalidade TLS no Serviço de Aplicações,
que requer que a sua aplicação esteja no nível Básico ou superior. Se a sua aplicação estiver em nível Livre ou
Par tilhado, pode incluir o ficheiro de certificado no seu repositóriode aplicações .
Quando permite que o Serviço de Aplicações gere os seus certificados TLS/SSL, pode manter os certificados e o
código de aplicação separadamente e salvaguardar os seus dados sensíveis.
Pré-requisitos
Criar uma aplicação do Serviço de Aplicações
Adicione um certificado à sua aplicação
Encontre a impressão digital

A partir da navegação à esquerda da sua aplicação, selecione as definições TLS/SSL, em seguida, selecione
Cer tificados de Chave Privada (.pfx) ou Certificados de Chave Pública (.cer) .
Encontre o certificado que pretende utilizar e copie a impressão digital.
Tornar o certificado acessível

Para aceder a um certificado no seu código WEBSITE_LOAD_CERTIFICATES de aplicações, adicione a sua impressão
digital à definição da aplicação, executando o seguinte comando na Cloud Shell:

WEBSITE_LOAD_CERTIFICATES=<comma-separated-certificate-thumbprints>
Para tornar todos os seus certificados * acessíveis, detete o valor para .

Certificado de carga em aplicativos Windows
A WEBSITE_LOAD_CERTIFICATES definição de aplicações torna os certificados especificados acessíveis à sua aplicação
hospedada no Windows na loja de certificados Windows, e a localização depende do nível de preços:
Nível isolado - em Máquina Local\My.
Todos os outros níveis - em Utilizador Atual\My.
No código C#, acede ao certificado pela impressão digital do certificado. O código seguinte carrega um
E661583E8FABEF4C0BEF694CBC41C28FB81CD870 certificado com a impressão digital .
using System;
using System.Linq;
using System.Security.Cryptography.X509Certificates;
string certThumbprint = "E661583E8FABEF4C0BEF694CBC41C28FB81CD870";

bool validOnly = false;
using (X509Store certStore = new X509Store(StoreName.My, StoreLocation.CurrentUser))

{
certStore.Open(OpenFlags.ReadOnly);
X509Certificate2Collection certCollection = certStore.Certificates.Find(

X509FindType.FindByThumbprint,
// Replace below with your certificate's thumbprint
certThumbprint,
validOnly);
// Get the first cert with the thumbprint
X509Certificate2 cert = certCollection.OfType<X509Certificate>().FirstOrDefault();
if (cert is null)
throw new Exception($"Certificate with thumbprint {certThumbprint} was not found");
// Use certificate
Console.WriteLine(cert.FriendlyName);
// Consider to call Dispose() on the certificate after it's being used, avaliable in .NET 4.6 and later
}
No código Java, acede ao certificado da loja "Windows-MY" utilizando o campo Nome Comum sujeito (ver
certificado de chave pública). O seguinte código mostra como carregar um certificado de chave privada:
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.bind.annotation.RequestMapping;
import java.security.KeyStore;
import java.security.cert.Certificate;
import java.security.PrivateKey;
...
KeyStore ks = KeyStore.getInstance("Windows-MY");
ks.load(null, null);
Certificate cert = ks.getCertificate("<subject-cn>");
PrivateKey privKey = (PrivateKey) ks.getKey("<subject-cn>", ("<password>").toCharArray());
// Use the certificate and key

...
Para idiomas que não suportem ou ofereçam suporte insuficiente para a loja de certificados Windows, consulte o
certificado de carga a partir do ficheiro.
Certificado de carga em aplicativos Linux

As WEBSITE_LOAD_CERTIFICATES definições da aplicação tornam os certificados especificados acessíveis às suas
aplicações hospedadas pelo Linux (incluindo aplicações de contentores personalizados) como ficheiros. Os
ficheiros são encontrados nos seguintes diretórios:
Certificados privados - /var/ssl/private (ficheiros) .p12
Certificados públicos - /var/ssl/certs (ficheiros) .der
Os nomes dos ficheiros do certificado são as impressões digitais do certificado. O código C# seguinte mostra
como carregar um certificado público numa aplicação Linux.
using System;
using System.IO;
...
var bytes = File.ReadAllBytes("/var/ssl/certs/<thumbprint>.der");
var cert = new X509Certificate2(bytes);
// Use the loaded certificate
Para ver como carregar um certificado TLS/SSL a partir de um ficheiro no Node.js, PHP, Python, Java ou Ruby,
consulte a documentação para o respetivo idioma ou plataforma web.
Certificado de carga a partir de arquivo

Se precisar de carregar um ficheiro de certificado que faça o upload manual, é melhor carregar o certificado
usando FTPS em vez de Git,por exemplo. Deve manter dados sensíveis como um certificado privado fora do
controlo de fonte.
NOTE
ASP.NET e ASP.NET Core no Windows devem aceder à loja de certificados mesmo que carregue um certificado de um ficheiro.
Para carregar um ficheiro de certificado numa aplicação Windows .NET, carregue o perfil de utilizador atual com o seguinte
comando na Cloud Shell:

WEBSITE_LOAD_USER_PROFILE=1
Esta abordagem à utilização de certificados no seu código utiliza a funcionalidade TLS no Serviço de Aplicações, que requer
que a sua aplicação esteja no nível Básico ou superior.
O exemplo C# seguinte carrega um certificado público de um caminho relativo na sua aplicação:
using System;
using System.IO;
...
var bytes = File.ReadAllBytes("~/<relative-path-to-cert-file>");
var cert = new X509Certificate2(bytes);
// Use the loaded certificate
Para ver como carregar um certificado TLS/SSL a partir de um ficheiro no Node.js, PHP, Python, Java ou Ruby,
consulte a documentação para o respetivo idioma ou plataforma web.
Mais recursos
Impor HTTPS
Impor TLS 1.1/1.2
Configure autenticação mútua TLS para serviço de
aplicações azure
Pode restringir o acesso à sua aplicação Azure App Service, permitindo-lhe diferentes tipos de autenticação. Uma
maneira de fazê-lo é solicitar um certificado de cliente quando o pedido do cliente for sobre TLS/SSL e validar o
certificado. Este mecanismo chama-se autenticação mútua TLS ou autenticação de certificado de cliente. Este
artigo mostra como configurar a sua app para utilizar a autenticação do certificado de cliente.
NOTE
Se aceder ao seu site em HTTP e não HTTPS, não receberá qualquer certificado de cliente. Portanto, se o seu pedido requer
certificados de cliente, não deve permitir pedidos para a sua candidatura em HTTP.

Para criar encadernações de segurança personalizadas ou ativar certificados de cliente para a sua app App Service,
o seu plano de Serviço de Aplicações deve estar no nível Básico , Standard , Premium ou Isolado. Neste passo,
vai confirmar que a aplicação Web está no escalão de preço suportado.

No painel de navegação esquerdo da página da aplicação Web, desloque-se para a secção Definições e selecione
caixa azul-escura.
passos na secção seguinte. Caso contrário, feche a página Scale up e salte a secção de plano seletiva para cima.
Selecione qualquer uma das camadas não gratuitas (B1 , B2 , B3 ou qualquer camada na categoria Produção ). Para
obter opções adicionais, clique em Ver opções adicionais .
Clique em Aplicar .
Ativar certificados de cliente

Para configurar a sua aplicação para exigir certificados de cliente, pode ligar o certificado de entrada
Requirecoming selecionando true Configurações Gerais de Configuração > do Portal Azure ou precisa definir
a clientCertEnabled definição para a sua app para . Para definir a definição, execute o seguinte comando na Cloud
Shell.
az webapp update --set clientCertEnabled=true --name <app_name> --resource-group <group_name>
Excluir caminhos da exigência de autenticação

Quando ativar a auth mútua para a sua aplicação, todos os caminhos sob a raiz da sua aplicação exigirão um
certificado de cliente para acesso. Para permitir que certos caminhos permaneçam abertos para acesso anónimo,
pode definir caminhos de exclusão como parte da configuração da sua aplicação.
Os caminhos de exclusão podem ser configurados selecionandoconfigurações gerais de configuração > e
definindo um caminho de exclusão. Neste exemplo, qualquer /public coisa em vias de aplicação não solicitaria
um certificado de cliente.
Certificado de cliente de acesso

No Serviço de Aplicações, a rescisão do pedido por TLS ocorre no equilíbrio de carga frontend. Ao reencaminhar o
pedido para o seu código de aplicações X-ARR-ClientCert com certificados de cliente ativados,o Serviço de
Aplicações injeta um cabeçalho de pedido com o certificado de cliente. O Serviço de Aplicações não faz nada com
este certificado de cliente a não ser reencaminhar para a sua aplicação. O seu código de aplicação é responsável
pela validação do certificado de cliente.
Para ASP.NET, o certificado de cliente está disponível através da propriedade HttpRequest.ClientCer tificate.
Para outras pilhas de aplicações (Node.js, PHP, etc.), o cliente cert está disponível na sua app através de um valor
codificado base64 no cabeçalho de X-ARR-ClientCert pedido.
ASP.NET amostra
using System;
using System.Collections.Specialized;
using System.Web;
namespace ClientCertificateUsageSample
{
public partial class Cert : System.Web.UI.Page
{
public string certHeader = "";
public string errorString = "";
public string errorString = "";
private X509Certificate2 certificate = null;
public string certThumbprint = "";
public string certSubject = "";
public string certIssuer = "";
public string certSignatureAlg = "";
public string certIssueDate = "";
public string certExpiryDate = "";
public bool isValidCert = false;
//
// Read the certificate from the header into an X509Certificate2 object
// Display properties of the certificate on the page
//
protected void Page_Load(object sender, EventArgs e)
{
NameValueCollection headers = base.Request.Headers;
certHeader = headers["X-ARR-ClientCert"];
if (!String.IsNullOrEmpty(certHeader))
{
try
{
byte[] clientCertBytes = Convert.FromBase64String(certHeader);
certificate = new X509Certificate2(clientCertBytes);
certSubject = certificate.Subject;
certIssuer = certificate.Issuer;
certThumbprint = certificate.Thumbprint;
certSignatureAlg = certificate.SignatureAlgorithm.FriendlyName;
certIssueDate = certificate.NotBefore.ToShortDateString() + " " +
certificate.NotBefore.ToShortTimeString();
certExpiryDate = certificate.NotAfter.ToShortDateString() + " " +
certificate.NotAfter.ToShortTimeString();
}
catch (Exception ex)
{
errorString = ex.ToString();
}
finally
{
isValidCert = IsValidClientCertificate();
if (!isValidCert) Response.StatusCode = 403;
else Response.StatusCode = 200;
}
}
else
{
certHeader = "";
}
}
//
// This is a SAMPLE verification routine. Depending on your application logic and security
requirements,
// you should modify this method
//
private bool IsValidClientCertificate()
{
// In this example we will only accept the certificate as a valid certificate if all the
conditions below are met:
// 1. The certificate is not expired and is active for the current time on server.
// 2. The subject name of the certificate has the common name nildevecc
// 3. The issuer name of the certificate has the common name nildevecc and organization name
Microsoft Corp
// 4. The thumbprint of the certificate is 30757A2E831977D8BD9C8496E4C99AB26CB9622B
//
// This example does NOT test that this certificate is chained to a Trusted Root Authority (or
revoked) on the server
// and it allows for self signed certificates
//
if (certificate == null || !String.IsNullOrEmpty(errorString)) return false;
// 1. Check time validity of certificate

if (DateTime.Compare(DateTime.Now, certificate.NotBefore) < 0 ||
DateTime.Compare(DateTime.Now, certificate.NotAfter) > 0) return false;
// 2. Check subject name of certificate

bool foundSubject = false;
string[] certSubjectData = certificate.Subject.Split(new char[] { ',' },
StringSplitOptions.RemoveEmptyEntries);
foreach (string s in certSubjectData)
{
if (String.Compare(s.Trim(), "CN=nildevecc") == 0)
{
foundSubject = true;
break;
}
}
if (!foundSubject) return false;
// 3. Check issuer name of certificate

bool foundIssuerCN = false, foundIssuerO = false;
string[] certIssuerData = certificate.Issuer.Split(new char[] { ',' },
StringSplitOptions.RemoveEmptyEntries);
foreach (string s in certIssuerData)
{
if (String.Compare(s.Trim(), "CN=nildevecc") == 0)
{
foundIssuerCN = true;
if (foundIssuerO) break;
}
if (String.Compare(s.Trim(), "O=Microsoft Corp") == 0)

{
foundIssuerO = true;
if (foundIssuerCN) break;
}
}
if (!foundIssuerCN || !foundIssuerO) return false;
// 4. Check thumprint of certificate

if (String.Compare(certificate.Thumbprint.Trim().ToUpper(),
"30757A2E831977D8BD9C8496E4C99AB26CB9622B") != 0) return false;
return true;
}
}
}
Amostra de Nó.js
O seguinte código de amostra Node.js recebe o X-ARR-ClientCert cabeçalho e utiliza a forja do nó para converter
a cadeia PEM codificada com base 64 num objeto de certificado e validá-lo:
import { NextFunction, Request, Response } from 'express';
import { pki, md, asn1 } from 'node-forge';
export class AuthorizationHandler {

public static authorizeClientCertificate(req: Request, res: Response, next: NextFunction): void {
try {
// Get header
const header = req.get('X-ARR-ClientCert');
if (!header) throw new Error('UNAUTHORIZED');
// Convert from PEM to pki.CERT

const pem = `-----BEGIN CERTIFICATE-----${header}-----END CERTIFICATE-----`;
const incomingCert: pki.Certificate = pki.certificateFromPem(pem);
// Validate certificate thumbprint

const fingerPrint =
md.sha1.create().update(asn1.toDer(pki.certificateToAsn1(incomingCert)).getBytes()).digest().toHex();
if (fingerPrint.toLowerCase() !== 'abcdef1234567890abcdef1234567890abcdef12') throw new
Error('UNAUTHORIZED');
// Validate time validity

const currentDate = new Date();
if (currentDate < incomingCert.validity.notBefore || currentDate > incomingCert.validity.notAfter)
throw new Error('UNAUTHORIZED');
// Validate issuer
if (incomingCert.issuer.hash.toLowerCase() !== 'abcdef1234567890abcdef1234567890abcdef12') throw
new Error('UNAUTHORIZED');
// Validate subject
if (incomingCert.subject.hash.toLowerCase() !== 'abcdef1234567890abcdef1234567890abcdef12') throw
new Error('UNAUTHORIZED');
next();
} catch (e) {
if (e instanceof Error && e.message === 'UNAUTHORIZED') {
res.status(401).send();
} else {
next(e);
}
}
}
}
Amostra de Java
A seguinte classe Java codifica X-ARR-ClientCert o X509Certificate certificado de uma instância.
certificateIsValid() valida que a impressão digital do certificado corresponde à dada no construtor e que o
certificado não expirou.
import java.io.ByteArrayInputStream;
import java.security.NoSuchAlgorithmException;
import java.security.cert.*;
import java.security.MessageDigest;
import sun.security.provider.X509Factory;
import javax.xml.bind.DatatypeConverter;
import java.util.Base64;
import java.util.Date;
public class ClientCertValidator {
private String thumbprint;

private X509Certificate certificate;
private X509Certificate certificate;
/**
* Constructor.
* @param certificate The certificate from the "X-ARR-ClientCert" HTTP header
* @param thumbprint The thumbprint to check against
* @throws CertificateException If the certificate factory cannot be created.
*/
public ClientCertValidator(String certificate, String thumbprint) throws CertificateException {
certificate = certificate
.replaceAll(X509Factory.BEGIN_CERT, "")
.replaceAll(X509Factory.END_CERT, "");
CertificateFactory cf = CertificateFactory.getInstance("X.509");
byte [] base64Bytes = Base64.getDecoder().decode(certificate);
X509Certificate X509cert = (X509Certificate) cf.generateCertificate(new
ByteArrayInputStream(base64Bytes));
this.setCertificate(X509cert);
this.setThumbprint(thumbprint);
}
/**
* Check that the certificate's thumbprint matches the one given in the constructor, and that the
* certificate has not expired.
* @return True if the certificate's thumbprint matches and has not expired. False otherwise.
*/
public boolean certificateIsValid() throws NoSuchAlgorithmException, CertificateEncodingException {
return certificateHasNotExpired() && thumbprintIsValid();
}
/**
* Check certificate's timestamp.
* @return Returns true if the certificate has not expired. Returns false if it has expired.
*/
private boolean certificateHasNotExpired() {
Date currentTime = new java.util.Date();
try {
this.getCertificate().checkValidity(currentTime);
} catch (CertificateExpiredException | CertificateNotYetValidException e) {
return false;
}
return true;
}
/**
* Check the certificate's thumbprint matches the given one.
* @return Returns true if the thumbprints match. False otherwise.
*/
private boolean thumbprintIsValid() throws NoSuchAlgorithmException, CertificateEncodingException {
MessageDigest md = MessageDigest.getInstance("SHA-1");
byte[] der = this.getCertificate().getEncoded();
md.update(der);
byte[] digest = md.digest();
String digestHex = DatatypeConverter.printHexBinary(digest);
return digestHex.toLowerCase().equals(this.getThumbprint().toLowerCase());
}
// Getters and setters
public void setThumbprint(String thumbprint) {

this.thumbprint = thumbprint;
}
public String getThumbprint() {

return this.thumbprint;
}
public X509Certificate getCertificate() {

return certificate;
}
public void setCertificate(X509Certificate certificate) {

this.certificate = certificate;
}
}
Encriptação em repouso usando chaves geridas pelo
cliente
Encriptar os dados da aplicação da sua aplicação web em repouso requer uma Conta de Armazenamento Azure e
um Cofre de Chave Azure. Estes serviços são utilizados quando executa a sua aplicação a partir de um pacote de
implementação.
O Armazenamento Azure fornece encriptação em repouso. Pode utilizar as chaves fornecidas pelo sistema ou as
suas próprias chaves geridas pelo cliente. É aqui que os dados da sua aplicação são armazenados quando não
está a ser gerido numa aplicação web em Azure.
A partir de um pacote de implementação é uma funcionalidade de implementação do Serviço de Aplicações.
Permite-lhe implementar o conteúdo do seu site a partir de uma conta de armazenamento Azure utilizando um
URL de Assinatura de Acesso Partilhado (SAS).
As referências chave vault são uma característica de segurança do Serviço de Aplicações. Permite-lhe importar
segredos no prazo de execução como definições de aplicação. Utilize isto para encriptar o URL SAS da sua Conta
de Armazenamento Azure.
Configurar encriptação em repouso

Criar uma conta de Armazenamento do Azure
Em primeiro lugar, crie uma conta de Armazenamento Azure e criptografe-a com chaves geridas pelo cliente. Assim
que a conta de armazenamento for criada, utilize o Azure Storage Explorer para carregar ficheiros de pacotes.
Em seguida, utilize o Explorador de Armazenamento para gerar um SAS.
NOTE
Guarde este URL SAS, este é utilizado mais tarde para permitir o acesso seguro do pacote de implementação em tempo de
execução.
Configure a partir de um pacote da sua conta de armazenamento

Assim que enviar o seu ficheiro para o armazenamento blob WEBSITE_RUN_FROM_PACKAGE e tiver um URL SAS para o
ficheiro, defina a definição de aplicação para o URL SAS. O exemplo seguinte fá-lo utilizando o Azure CLI:

WEBSITE_RUN_FROM_PACKAGE="<your-SAS-URL>"
A adição desta definição de aplicação faz com que a sua aplicação web reinicie. Depois de a aplicação ter reiniciado,
navegue para a aplicação e certifique-se de que a aplicação começou a utilizar corretamente o pacote de
implementação. Se a aplicação não tiver começado corretamente, consulte a Corrida do guia de resolução de
problemas do pacote.
Criptografe a definição de aplicação utilizando referências chave vault
Agora pode substituir o WEBSITE_RUN_FROM_PACKAGE valor da definição de aplicação por uma referência chave vault
ao URL codificado pela SAS. Isto mantém o URL SAS encriptado no Cofre chave, que fornece uma camada extra de
segurança.
1. Utilize o az keyvault create seguinte comando para criar uma instância chave vault.
az keyvault create --name "Contoso-Vault" --resource-group <group-name> --location eastus
2. Siga estas instruções para dar acesso à sua aplicação ao seu cofre chave:
3. Utilize o az keyvault secret set seguinte comando para adicionar o seu URL externo como um segredo no
seu cofre chave:
az keyvault secret set --vault-name "Contoso-Vault" --name "external-url" --value "<SAS-URL>"
4. Utilize o az webapp config appsettings set seguinte comando WEBSITE_RUN_FROM_PACKAGE para criar a
definição de aplicação com o valor como referência do Cofre chave ao URL externo:
az webapp config appsettings set --settings

WEBSITE_RUN_FROM_PACKAGE="@Microsoft.KeyVault(SecretUri=https://Contoso-
Vault.vault.azure.net/secrets/external-url/<secret-version>"
O <secret-version> estará na saída do az keyvault secret set comando anterior.
Atualizar esta definição de aplicação faz com que a sua aplicação web reinicie. Depois de a aplicação ter reiniciado,
procure-a para se certificar de que começou corretamente a utilizar a referência do Cofre chave.
Como rodar o símbolo de acesso

É uma boa prática rodar periodicamente a chave SAS da sua conta de armazenamento. Para garantir que a
aplicação web não perde inadvertidamente o acesso, também deve atualizar o URL SAS no Cofre de Chaves.
1. Rode a tecla SAS navegando para a sua conta de armazenamento no portal Azure. Em definições > As
teclas de acesso, clique no ícone para rodar a tecla SAS.
2. Copie o novo URL SAS e utilize o seguinte comando para definir o URL SAS atualizado no seu cofre chave:
az keyvault secret set --vault-name "Contoso-Vault" --name "external-url" --value "<SAS-URL>"
3. Atualize a referência do cofre chave na definição da sua aplicação para a nova versão secreta:
az webapp config appsettings set --settings

WEBSITE_RUN_FROM_PACKAGE="@Microsoft.KeyVault(SecretUri=https://Contoso-
Vault.vault.azure.net/secrets/external-url/<secret-version>"
O <secret-version> estará na saída do az keyvault secret set comando anterior.
Como revogar o acesso de dados da aplicação web

Existem dois métodos para revogar o acesso da aplicação web à conta de armazenamento.
Rode a tecla SAS para a conta de armazenamento azure
Se a chave SAS para a conta de armazenamento for rotativa, a aplicação web deixará de ter acesso à conta de
armazenamento, mas continuará a funcionar com a última versão descarregada do ficheiro do pacote. Reinicie a
aplicação web para limpar a última versão descarregada.
Remova o acesso da aplicação web ao Key Vault
Pode revogar o acesso da aplicação web aos dados do site, desativando o acesso da aplicação web ao Key Vault.
Para tal, remova a política de acesso à identidade da aplicação web. Esta é a mesma identidade que criou
anteriormente enquanto configura referências chave do cofre.
Resumo
Os ficheiros de aplicação estão agora encriptados em repouso na sua conta de armazenamento. Quando a sua
aplicação web começa, ele recupera o URL SAS do seu cofre chave. Finalmente, a aplicação web carrega os ficheiros
da aplicação a partir da conta de armazenamento.
Se precisar de revogar o acesso da aplicação web à sua conta de armazenamento, pode revogar o acesso ao cofre
da chave ou rodar as chaves da conta de armazenamento, o que invalida o URL SAS.
Perguntas Mais Frequentes

Há algum custo adicional para executar a minha aplicação web a partir do pacote de implementação?
Apenas o custo associado à Conta de Armazenamento Azure e quaisquer encargos de saída aplicáveis.
Como é que o funcionamento do pacote de implementação afeta a minha aplicação web?
Executar a sua aplicação wwwroot/ a partir do pacote de implementação faz apenas leitura. A sua aplicação
recebe um erro quando tenta escrever para este diretório.
Os formatos TAR e GZIP não são suportados.
Esta funcionalidade não é compatível com a cache local.
Passos seguintes
Referências chave vault para serviço de aplicações
Encriptação azure storage para dados em repouso
Aumentar uma aplicação no Azure App Service
Este artigo mostra-lhe como escalar a sua app no Azure App Service. Existem dois fluxos de trabalho para
escala, escala e escala, e este artigo explica a escala de fluxo de trabalho.
Escala para cima: Obtenha mais CPU, memória, espaço em disco e funcionalidades extra como máquinas
virtuais dedicadas (VMs), domínios e certificados personalizados, slots de encenação, autoscalcificação e
muito mais. Escala-se alterando o nível de preços do plano de Serviço de Aplicações a que a sua aplicação
pertence.
Escala para fora: Aumente o número de casos vm que executam a sua aplicação. Pode aumentar até 30
instâncias, dependendo do seu nível de preços. O App Service Environments em nível isolado aumenta
ainda mais a sua contagem de escala para 100 instâncias. Para obter mais informações sobre o
escalonamento, consulte a contagem de exemplos de escala manualmente ou automaticamente. Lá, você
descobre como usar autoscalcificação, que é escalar a contagem de instâncias automaticamente com base
em regras e horários pré-definidos.
As definições de escala demoram apenas alguns segundos a aplicar e a afetar todas as aplicações do seu
plano de Serviço de Aplicações. Não exigem que altere o seu código ou reimplemente a sua aplicação.
Para obter informações sobre os preços e funcionalidades dos planos individuais do App Service, consulte os
detalhes dos preços do serviço de aplicações.
NOTE
Antes de mudar um plano de Serviço de Aplicações do free tier, primeiro deve remover os limites de gastos em vigor
para a sua subscrição Azure. Para visualizar ou alterar opções para a subscrição do Microsoft Azure App Service,
consulte as subscrições do Microsoft Azure.
Aumentar o seu nível de preços

NOTE
Para escalar até ao nível PremiumV2, consulte o nível Configure PremiumV2 para o Serviçode Aplicações .
1. No browser, abra o portal do Azure.

2. Na página da sua aplicação App Service, a partir do menu esquerdo, selecione Scale Up (plano de
serviço de aplicações) .
3. Escolha o seu nível e, em seguida, selecione Aplicar . Selecione as diferentes categorias (por exemplo,
Produção) e consulte também opções adicionais para mostrar mais níveis.
Quando a operação estiver concluída, vê-se um pop-up de notificação com uma marca de verificação
de sucesso verde.
Recursos relacionados com escala

Se a sua aplicação depender de outros serviços, como o Azure SQL Database ou o Azure Storage, pode
aumentar esses recursos separadamente. Estes recursos não são geridos pelo plano de Serviço de Aplicações.
1. Na página 'Visão Geral' da sua aplicação, selecione o link do grupo Recurso.
2. Na parte resumo da página do grupo Recursos, selecione um recurso que pretende escalar. A
imagem que se segue mostra um recurso de base de dados SQL.
Para aumentar o recurso relacionado, consulte a documentação para o tipo de recurso específico. Por
exemplo, para aumentar uma única base de dados SQL, consulte os recursos de base de dados
individuais da Escala na Base de Dados Azure SQL. Para escalar uma Base de Dados Azure para o
recurso MySQL, consulte os recursos Scale MySQL.
Comparar níveis de preços

Para obter informações detalhadas, tais como tamanhos vm para cada nível de preços, consulte detalhes de
preços do serviço de aplicações.
Para uma tabela de limites de serviço, quotas e restrições, e funcionalidades suportadas em cada nível,
consulte os limites do Serviço de Aplicações.
Mais recursos
Scale instance count manually or automatically (Dimensionar a contagem de instâncias manual ou
automaticamente)
Configure o nível PremiumV2 para o Serviço de Aplicações
Configure premiumV2 nível para serviço de
aplicações Azure
O novo nível de preços PremiumV2 dá-lhe processadores mais rápidos, armazenamento SSD e duplica a relação
memória-núcleo dos níveis de preços existentes. Com a vantagem de desempenho, você poderia economizar
dinheiro executando as suas aplicações em menos casos. Neste artigo, aprende-se a criar uma aplicação no
escalão PremiumV2 ou a aumentar uma aplicação para o nível PremiumV2.
Pré-requisitos
Para escalar uma aplicação para PremiumV2, é necessário ter uma app Azure App Service que seja de um nível
de preços inferior ao PremiumV2 , e a aplicação deve estar a funcionar numa implementação do App Service que
suporta o PremiumV2.
Disponibilidade PremiumV2
O nível PremiumV2 está disponível para o Serviço de Aplicações tanto no Windows como no Linux.
PremiumV2 está disponível na maioria das regiões do Azure. Para ver se está disponível na sua região, execute o
seguinte comando Azure CLI na Concha da Nuvem Azure:
az appservice list-locations --sku P1V2
Criar uma aplicação no escalão PremiumV2

O nível de preços de uma aplicação do App Service está definido no plano do App Service em que funciona. Pode
criar um plano de Serviço de Aplicações por si só ou como parte da criação de apps.
Ao configurar o plano de serviço de aplicações no portal Azure,selecione o nível de preços .
Selecione Produção, depois selecione P1V2, P2V2 , ou P3V2, em seguida, clique em Aplicar .
IMPORTANT
Se não vir p1V2, P2V2 e P3V2 como opções, ou se as opções estiverem acinzentadas, então o PremiumV2
provavelmente não está disponível na implementação subjacente do Serviço de Aplicações que contém o plano de Serviço
de Aplicações. Consulte a Scale up de um grupo de recursos não apoiados e uma combinação de região para mais detalhes.
Aumentar uma app existente para o nível PremiumV2

Antes de escalonar uma aplicação existente para o nível PremiumV2, certifique-se de que o PremiumV2 está
disponível. Para obter informações, consulte a disponibilidade premiumV2. Se não estiver disponível, consulte
scale up de um grupo de recursos não apoiado e combinação de região.
Dependendo do ambiente de hospedagem, a escalada pode exigir passos extra.
No portal Azure,abra a sua página de aplicações do App Service.
Na navegação à esquerda da sua página de aplicações do App Service, selecione Scale up (plano de serviço de
aplicações) .
Selecione Produção, depois selecione P1V2, P2V2 , ou P3V2, em seguida, clique em Aplicar .
Se a sua operação terminar com sucesso, a página geral da sua aplicação mostra que está agora num nível
PremiumV2.
Se tiver um erro
Alguns planos de Serviço de Aplicações não podem escalar até ao nível PremiumV2 se a implementação
subjacente ao Serviço de Aplicações não suportar o PremiumV2. Consulte a Scale up de um grupo de recursos
não apoiados e uma combinação de região para mais detalhes.
Escala de um grupo de recursos não apoiados e combinação de região

Se a sua aplicação for implementada numa implementação do Serviço de Aplicações onde o PremiumV2 não
esteja disponível, ou se a sua aplicação for executado numa região que atualmente não suporta o PremiumV2,
terá de reutilizar a sua aplicação para tirar partido do PremiumV2 . Tem duas opções:
Crie um novo grupo de recursos e, em seguida, crie um novo plano de aplicação e app service no novo
grupo de recursos, escolhendo a sua região azure desejada durante o processo de criação. Deve must
selecionar o plano PremiumV2 no momento em que o novo plano de serviço de aplicações é criado. Isto
garante a combinação de grupo de recursos, plano de serviço de aplicações e região do Azure resultará na
criação do plano de Serviço de Aplicações numa implementação do Serviço de Aplicações que suporta o
PremiumV2 . Em seguida, recoloque o seu código de aplicação no plano de aplicação e serviço de
aplicações recém-criado. Se desejar, poderá posteriormente reduzir o plano de Serviço de Aplicações do
PremiumV2 para economizar custos, e ainda assim poderá voltar a escalar com sucesso no futuro
utilizando o PremiumV2 .
Se a sua aplicação já estiver em funcionamento num nível Premium existente, então pode clonar a sua
aplicação com todas as definições de aplicações, cordas de ligação e configuração de implementação num
novo plano de serviço de aplicações que utiliza premiumV2 .
Na página da aplicação Clone, pode criar um plano de Serviço de Aplicações utilizando premiumV2 na
região que deseja, e especificar as definições e configurações da aplicação que pretende clonar.
Pode automatizar a criação de aplicações no nível PremiumV2 com scripts, utilizando o Azure CLI ou o Azure
PowerShell.
CLI do Azure
O seguinte comando cria um plano de Serviço de Aplicações em P1V2. Podes executá-lo na Cloud Shell. As
opções para --sku são P1V2, _P2V2_e P3V2.
az appservice plan create \

--resource-group <resource_group_name> \
--name <app_service_plan_name> \
--sku P1V2
Azure PowerShell
NOTE
O seguinte comando cria um plano de Serviço de Aplicações em P1V2. As opções -WorkerSize para são
Pequenas, _Médias_e Grandes.
New-AzAppServicePlan -ResourceGroupName <resource_group_name> `

-Name <app_service_plan_name> `
-Location <region_name> `
-Tier "PremiumV2" `
-WorkerSize "Small"
Mais recursos
Aumentar verticalmente uma aplicação no Azure
Scale instance count manually or automatically (Dimensionar a contagem de instâncias manual ou
automaticamente)
Introdução ao Dimensionamento Automático no
Azure
Este artigo descreve como configurar as definições de escala automática para o seu recurso no portal Microsoft
Azure.
A escala automática Do Monitor Azure aplica-se apenas a conjuntos de escala de máquinas virtuais, serviços de
cloud, serviço de aplicações - Aplicações Webe serviços de Gestão API.
Descubra as definições de escala automática na sua subscrição

Pode descobrir todos os recursos para os quais a Escala Automática é aplicável no Monitor Azure. Utilize os
seguintes passos para uma passagem passo a passo:
1. Abra o portal Azure.
2. Clique no ícone Do Monitor Azure no painel esquerdo.
3. Clique em Escala Automática para ver todos os recursos para os quais a Escala Automática é aplicável,
juntamente com o seu estado atual de escala Automática.
Pode utilizar o painel de filtros na parte superior para analisar a lista para selecionar recursos num grupo de
recursos específicos, tipos de recursos específicos ou um recurso específico.
Para cada recurso, encontrará a contagem de instâncias atuais e o estado de escala automática. O estado de escala
automática pode ser:
Não configurado : Ainda não ativou a Escala Automática para este recurso.
Ativado : Ativou a escala Automática para este recurso.
Desativado: Desativou a escala automática para este recurso.
Crie a sua primeira definição de escala automática

Vamos agora passar por uma simples passagem passo a passo para criar a sua primeira definição de escala
automática.
1. Abra a lâmina de escala automática no Monitor Azure e selecione um recurso que pretende escalar. (Os
seguintes passos utilizam um plano de Serviço de Aplicações associado a uma aplicação web. Pode criar a
sua primeira ASP.NET aplicação web em Azure em 5 minutos.
2. Note que a contagem de instâncias atuais é 1. Clique em ativar a escala automática .
3. Forneça um nome para a definição de escala e, em seguida, clique em Adicionar uma regra . Note as
opções de regra de escala que se abrem como um painel de contexto no lado direito. Por padrão, isto define
a opção de escalar a sua contagem de instâncias em 1 se a percentagem de CPU do recurso exceder 70%.
Deixe-o nos seus valores padrão e clique em Adicionar .
4. Agora criaste a tua regra de primeira escala. Note que o UX recomenda as melhores práticas e afirma que
"recomenda-se ter pelo menos uma escala em regra." Para tal:
a. Clique em Adicionar uma regra .
b. Definir operador para menos de .
c. Definir limiar para 20 .
d. Definir Operação para Diminuir a contagem por .
Deve agora ter uma regulação de escala que escala/escala sem escalas com base na utilização do CPU.
5. Clique em Guardar .
Parabéns! Criou com sucesso a sua definição de primeira escala para escalar automaticamente a sua aplicação web
com base no uso do CPU.
NOTE
Os mesmos passos são aplicáveis para começar com um conjunto de escala de máquina virtual ou função de serviço em
nuvem.
Outras considerações
Escala com base num horário
Além da escala baseada no CPU, pode definir a sua escala de forma diferente para dias específicos da semana.
1. Clique Em adicionar uma condição de escala .
2. A definição do modo de escala e as regras são as mesmas que a condição predefinida.
3. Selecione Repita os dias específicos para o horário.
4. Selecione os dias e o tempo de início/fim para quando a condição de escala deve ser aplicada.
Escala de forma diferente em datas específicas

Além da escala baseada no CPU, pode definir a sua escala de forma diferente para datas específicas.
1. Clique Em adicionar uma condição de escala .
2. A definição do modo de escala e as regras são as mesmas que a condição predefinida.
3. Selecione Especificar as datas de início/fim para o horário.
4. Selecione as datas de início/fim e o tempo de início/fim para quando a condição de escala deve ser aplicada.
Veja a história da escala do seu recurso
Sempre que o seu recurso é dimensionado para cima ou para baixo, um evento é registado no registo de atividade.
Pode ver a história da escala do seu recurso nas últimas 24 horas, mudando para o separador histórico Run.
Se quiser ver o histórico de escala completa (por um prazo de até 90 dias), selecione Clique aqui para ver mais
detalhes . O registo de atividade abre, com escala automática pré-selecionada para o seu recurso e categoria.
Veja a definição de escala do seu recurso
A escala automática é um recurso do Gestor de Recursos Azure. Pode visualizar a definição de escala em JSON,
mudando para o separador JSON.
Pode fazer alterações na JSON diretamente, se necessário. Estas alterações serão refletidas depois de as salvares.
Desative a escala automática e escala manualmente as suas instâncias
Pode haver momentos em que pretende desativar a sua regulação de escala atual e escalar manualmente o seu
recurso.
Clique no botão de desativação de escala automática na parte superior.
NOTE
Esta opção desativa a sua configuração. No entanto, pode voltar a fazê-lo depois de voltar a ativar a Escala Automática.
Agora pode definir o número de instâncias que pretende escalar manualmente.
Pode sempre voltar à escala automática clicando em escala automática e, em seguida, guardar .
Passos seguintes
Crie um Alerta de Registo de Atividades para monitorizar todas as operações do motor de escala automática na
sua subscrição
Crie um Alerta de Registo de Atividades para monitorizar todas as operações falhadas de escala
automática/escala na sua subscrição
Hospedagem de alta densidade no Serviço de
Aplicações Azure usando escala por app
NOTE
Ao utilizar o App Service, pode escalar as suas aplicações escalando o plano de Serviço de Aplicações em que
funcionam. Quando várias aplicações são executadas no mesmo plano de App Service, cada instância em escala
executa todas as aplicações do plano.
A escala por aplicação pode ser ativada ao nível do plano do App Service para permitir a escala de uma aplicação
independentemente do plano de Serviço de Aplicações que a acolhe. Desta forma, um plano de Serviço de
Aplicações pode ser dimensionado para 10 instâncias, mas uma aplicação pode ser definida para usar apenas cinco.
NOTE
A escala por app está disponível apenas para os níveis de preços Standard, Premium, Premium V2 e Isolados.
As aplicações são atribuídas ao plano de Serviço de Aplicações disponível, utilizando uma melhor abordagem de
esforço para uma distribuição uniforme em instâncias. Embora não seja garantida uma distribuição uniforme, a
plataforma garantirá que duas instâncias da mesma aplicação não serão alojadas na mesma instância do plano de
app Service.
A plataforma não depende de métricas para decidir sobre a atribuição de trabalhadores. As aplicações só são
reequilibradas quando as instâncias são adicionadas ou removidas do plano de Serviço de Aplicações.
Por escala de aplicativo usando PowerShell

Crie um plano com escala por app -PerSiteScaling $true passando New-AzAppServicePlan o parâmetro para o
cmdlet.
New-AzAppServicePlan -ResourceGroupName $ResourceGroup -Name $AppServicePlan `

-Location $Location `
-Tier Premium -WorkerSize Small `
-NumberofWorkers 5 -PerSiteScaling $true
Ative a escala por app com um Plano de -PerSiteScaling $true Serviço de Set-AzAppServicePlan Aplicações
existente, passando o parâmetro para o cmdlet.
# Enable per-app scaling for the App Service Plan using the "PerSiteScaling" parameter.
Set-AzAppServicePlan -ResourceGroupName $ResourceGroup `
-Name $AppServicePlan -PerSiteScaling $true
Ao nível da aplicação, configure o número de casos que a aplicação pode usar no plano do Serviço de Aplicações.
No exemplo abaixo, a aplicação está limitada a duas instâncias, independentemente de quantas instâncias o plano
de serviço de aplicações subjacente se baseia.
# Get the app we want to configure to use "PerSiteScaling"

$newapp = Get-AzWebApp -ResourceGroupName $ResourceGroup -Name $webapp
# Modify the NumberOfWorkers setting to the desired value.

$newapp.SiteConfig.NumberOfWorkers = 2
# Post updated app back to azure

Set-AzWebApp $newapp
IMPORTANT
$newapp.SiteConfig.NumberOfWorkers é diferente $newapp.MaxNumberOfWorkers de . A escala por app
$newapp.SiteConfig.NumberOfWorkers utiliza para determinar as características de escala da aplicação.
Escala por app usando O Gestor de Recursos Azure

O seguinte modelo de Gestor de Recursos Azure cria:
Um plano de serviço de aplicações que é escalado para 10 instâncias
uma aplicação que está configurada para escalar para um máximo de cinco instâncias.
O plano do Serviço de Aplicações está "perSiteScaling": true a definir a propriedade PerSiteScaling como
verdadeira . A aplicação está a definir o "properties": { "numberOfWorkers": "5" } número de trabalhadores para
usar para 5 .
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters":{
"appServicePlanName": { "type": "string" },
"appName": { "type": "string" }
},
"resources": [
{
"comments": "App Service Plan with per site perSiteScaling = true",
"type": "Microsoft.Web/serverFarms",
"sku": {
"name": "P1",
"tier": "Premium",
"size": "P1",
"family": "P",
"capacity": 10
},
"name": "[parameters('appServicePlanName')]",
"apiVersion": "2015-08-01",
"location": "West US",
"properties": {
"name": "[parameters('appServicePlanName')]",
"perSiteScaling": true
}
},
{
"name": "[parameters('appName')]",
"apiVersion": "2015-08-01-preview",
"dependsOn": [ "[resourceId('Microsoft.Web/serverFarms', parameters('appServicePlanName'))]" ],
"properties": { "serverFarmId": "[resourceId('Microsoft.Web/serverFarms',
parameters('appServicePlanName'))]" },
"resources": [ {
"comments": "",
"type": "config",
"name": "web",
"apiVersion": "2015-08-01",
"dependsOn": [ "[resourceId('Microsoft.Web/Sites', parameters('appName'))]" ],
"properties": { "numberOfWorkers": "5" }
} ]
}]
}
Configuração recomendada para hospedagem de alta densidade

Por escala de aplicativos é uma funcionalidade que está ativada tanto nas regiões globais do Azure como nos
Ambientes de Serviços de Aplicações. No entanto, a estratégia recomendada é utilizar os Ambientes de Serviço de
Aplicações para tirar partido das suas funcionalidades avançadas e da maior capacidade do plano de aplicações.
Siga estes passos para configurar hospedagem de alta densidade para as suas apps:
1. Designe um plano de Serviço de Aplicações como o plano de alta densidade e escalda-o para a capacidade
desejada.
2. Coloque PerSiteScaling a bandeira verdadeirano plano de Serviço de Aplicações.
3. Novas aplicações são criadas e atribuídas a esse plano de Serviço de Aplicações com o número de propriedades
Dos Trabalhadores definido para 1 .
A utilização desta configuração produz a maior densidade possível.
4. O número de trabalhadores pode ser configurado de forma independente por app para conceder recursos
adicionais conforme necessário. Por exemplo:
Uma aplicação de alta utilização pode definir o númeroOfWorkers para 3 para ter mais capacidade de
processamento para essa aplicação.
As aplicações de baixo uso definiriam o númeroOfWorkers para 1 .
Passos seguintes
Planos de serviço de aplicação azure em profundidade
Introdução ao Ambiente do Serviço de Aplicações
Monitorize aplicações no Serviço de Aplicações
Azure
O Azure App Service fornece funcionalidades de monitorização incorporadas para aplicações web, aplicações
móveis e API no portal Azure.
No portal Azure, pode rever quotas e métricas para um plano de app e app service, e configurar alertas e
métricas baseadas em regras de autoscalcificação.
Compreender quotas
As aplicações que estão hospedadas no App Service estão sujeitas a certos limites nos recursos que podem
utilizar. Os limites são definidos pelo plano de Serviço de Aplicações que está associado à aplicação.
NOTE
Se a aplicação estiver hospedada num plano Gratuito ou Partilhado, os limites dos recursos que a app pode
utilizar são definidos por quotas.
Se a aplicação estiver alojada num plano Basic, Standard, ou Premium, os limites dos recursos que podem utilizar
são definidos pelo tamanho (Pequeno, Médio, Grande) e contagem de instâncias (1, 2, 3, e assim por diante) do
plano de Serviço de Aplicações.
Quotas para aplicações gratuitas ou partilhadas são:
Q UOTA DESC RIÇ Ã O
CPU (Cur to) A quantidade de CPU permitida para esta aplicação num
intervalo de 5 minutos. Esta quota repõe a cada cinco
minutos.
CPU (Dia) A quantidade total de CPU permitida para esta aplicação em

um dia. Esta quota repõe a cada 24 horas à meia-noite UTC.
Memória A quantidade total de memória permitida para esta aplicação.
Largura de banda A quantidade total de largura de banda de saída permitida

para esta aplicação num dia. Esta quota repõe a cada 24
horas à meia-noite UTC.
Filesystem A quantidade total de armazenamento permitida.
A única quota aplicável às aplicações hospedadas em Basic, Standarde Premium é o Sistema de Ficheiros.
Para obter mais informações sobre as quotas, limites e funcionalidades específicas disponíveis para as várias
SKUs do Serviço de Aplicações, consulte os limites do serviço de subscrição azure.
Aplicação de quotas
Se uma aplicação exceder o CPU (curto) CPU (Dia), ou quota de largura de banda, a aplicação é interrompida até
que a quota reset. Durante este período, todos os pedidos de entrada resultam num erro HTTP 403.
Se a quota de memória da aplicação for ultrapassada, a aplicação é interrompida temporariamente.

Se a quota do Sistema de Ficheiros for excedida, qualquer operação de escrita falha. As falhas de operação de
escrita incluem quaisquer escritos para registos.
Pode aumentar ou remover quotas da sua app atualizando o seu plano de Serviço de Aplicações.
Compreender as métricas
NOTE
O Uso do Sistema de Ficheiros é uma nova métrica a ser lançada globalmente, não são esperados dados a não ser que
tenha sido listado em branco para pré-visualização privada.
IMPORTANT
O tempo médio de resposta será premeditado para evitar confusões com agregações métricas. Utilize o Tempo de
Resposta como substituto.
As métricas fornecem informações sobre o comportamento da app ou do plano de serviço de aplicações.

Para uma aplicação, as métricas disponíveis são:
M ÉT RIC A DESC RIÇ Ã O
Tempo de Resposta O tempo que a app demorou a servir pedidos, em segundos.
Tempo médio de resposta (depreciado) O tempo médio de tempo para a app servir pedidos, em
segundos.
Conjunto de trabalho médio da memória A quantidade média de memória usada pela app, em
megabytes (MiB).
Ligações O número de tomadas ligadas existentes na caixa de areia

(w3wp.exe e os seus processos infantis). Uma tomada de
atrelado é criada através da ligação ()/ligação() APIs e
permanece até que a tomada seja fechada com
CloseHandle()/closesocket().
Tempo cpu A quantidade de CPU consumida pela app, em segundos.

Para obter mais informações sobre esta métrica, consulte o
tempo de CPU vs cpu percentual.
Assembleias atuais O número atual de Assembléias carregados em todos os

AppDomains nesta aplicação.
Dados em A quantidade de largura de banda consumida pela app, no

MiB.
Dados out A quantidade de largura de banda de saída consumida pela

app, no MiB.
Utilização do sistema de ficheiros Percentagem de quota de sistema de ficheiros consumida

pela app.
Coleções de lixo gen 0 O número de vezes que os objetos da geração 0 são

recolhidos lixo desde o início do processo da aplicação. GCs
de geração superior incluem todos os GCs de geração
inferior.
Coleções de lixo da Gen 1 O número de vezes que os objetos da geração 1 são

recolhidos lixo desde o início do processo da aplicação. GCs
de geração superior incluem todos os GCs de geração
inferior.
Coleções de lixo gen 2 O número de vezes que os objetos da geração 2 são

recolhidos lixo desde o início do processo da aplicação.
N.º de Identificadores O número total de pegas atualmente abertas pelo processo

da aplicação.
Http 2xx A contagem de pedidos que resulta num código de estado

HTTP ≥ 200, mas < 300.

HTTP ≥ 300, mas < 400.
Http 401 A contagem de pedidos que resultam no código de estado

HTTP 401.

HTTP 403.

HTTP 404.

HTTP 406.

HTTP ≥ 400, mas < 500.
Erros do ser vidor http A contagem de pedidos que resulta num código de estado
HTTP ≥ 500, mas < 600.
IO Outros Bytes por Segundo A taxa a que o processo da aplicação está a emitir bytes para
operações de I/O que não envolvem dados, como operações
de controlo.
IO outras operações por segundo A taxa a que o processo da aplicação está a emitir operações
de I/S que não são operações de leitura ou escrita.
IO Ler Bytes por Segundo A taxa a que o processo da aplicação está a ler bytes de
operações de I/O.
IO Ler Operações por segundo A taxa a que o processo da aplicação está a emitir operações
de I/O.
IO Escrever Bytes por Segundo A taxa a que o processo da aplicação está a escrever bytes
para operações de I/O.
IO Write Operations por segundo A taxa a que o processo da aplicação está a emitir operações
de E/S.
Conjunto de trabalho de memória A quantidade atual de memória usada pela app, no MiB.
Bytes Privados Private Bytes é o tamanho atual, em bytes, de memória que

o processo de aplicação atribuiu que não pode ser partilhado
com outros processos.
Pedidos O número total de pedidos, independentemente do seu

código de estado HTTP resultante.
Pedidos na fila de candidaturas O número de pedidos na fila do pedido de pedido de pedido.
Contagem de fios O número de fios atualmente ativos no processo da

aplicação.
Domínios totais de aplicativos O número atual de AppDomains carregados nesta aplicação.
Total de domínios de aplicativos descarregados O número total de AppDomains descarregados desde o

início da aplicação.
Para um plano de Serviço de Aplicações, as métricas disponíveis são:

NOTE
As métricas do plano de serviço de aplicações estão disponíveis apenas para planos nos níveis Basic, Standarde Premium.
Percentagem de CPU A CPU média usada em todos os casos do plano.
Percentagem de Memória A memória média usada em todos os casos do plano.
Dados em A largura de banda média de entrada usada em todos os

casos do plano.
Dados out A largura de banda média de saída usada em todos os casos

do plano.
Comprimento da fila do disco O número médio de pedidos de leitura e escrita que foram
em fila no armazenamento. Um comprimento de fila de disco
elevado é uma indicação de uma aplicação que pode estar a
abrandar devido ao excesso de I/O do disco.
Comprimento da fila http O número médio de pedidos de HTTP que tiveram de se

sentar na fila antes de serem cumpridos. Um comprimento
de fila http elevado ou crescente é um sintoma de um plano
sob carga pesada.
CpU tempo vs CPU percentagem

Existem duas métricas que refletem o uso do CPU:
Tempo cpu : Útil para apps hospedadas em planos gratuitos ou partilhados, porque uma das suas quotas é
definida em minutos de CPU usados pela app.
Percentagem de CPU : Útil para apps hospedadas em planos Básicos, Standard e Premium, porque podem ser
dimensionados. A percentagem de CPU é uma boa indicação da utilização global em todos os casos.
Política de granularidade e retenção de métricas

As métricas para um plano de serviço de aplicações e aplicações são registadas e agregadas pelo serviço e
mantidas de acordo com estas regras.
Quotas e métricas de monitorização no portal Azure

Para rever o estado das várias quotas e métricas que afetam uma app, vá ao portal Azure.
Para encontrar quotas, selecioneQuotas de Definições > . Na tabela, pode rever:
1. O nome da quota.
2. O intervalo de reset.
3. O seu limite atual.
4. O seu valor atual.
Azure Pode aceder às métricas diretamente a partir da página de visão geral do recurso. Aqui você verá
gráficos que representam algumas das métricas das aplicações.
Clicar em qualquer um desses gráficos irá levá-lo à vista das métricas onde você pode criar gráficos
personalizados, consultando métricas diferentes e muito mais.
Para saber mais sobre métricas, consulte as métricasde serviço monitor .
Alertas e escala automática

As métricas de uma aplicação ou de um plano de Serviço de Aplicações podem ser ligadas a alertas. Para obter
mais informações, consulte Receber notificações de alerta.
Aplicativos de Serviço de Aplicações hospedados em planos básicos ou superiores do App Service suportam a
escala automática. Com escala automática, pode configurar regras que monitorizam as métricas do plano do App
Service. As regras podem aumentar ou diminuir a contagem de casos, que pode fornecer recursos adicionais
conforme necessário. As regras também podem ajudá-lo a economizar dinheiro quando a aplicação está sobre-
provisionada.
Para mais informações sobre escala automática, consulte Como escalar e as melhores práticas para
autoscalcificação do Monitor Azure.
Ativar diagnósticos de login para apps no Serviço de
Aplicações Azure
Descrição geral
O Azure fornece diagnósticos incorporados para ajudar a depurar uma aplicação de Serviço de Aplicações. Neste
artigo, aprende-se a permitir o registo de diagnóstico e a adicionar instrumentação à sua aplicação, bem como
como aceder à informação registada pelo Azure.
Este artigo utiliza o portal Azure e o Azure CLI para trabalhar com registos de diagnóstico. Para obter informações
sobre o trabalho com registos de diagnóstico utilizando o Visual Studio, consulte Troubleshooting Azure em
Visual Studio.
NOTE
Além das instruções de registo neste artigo, há uma nova capacidade de exploração madeireira integrada com a
Monitorização Azure. Você encontrará mais sobre esta capacidade na secção Enviar para o Monitor Azure (pré-visualização).
T IP O P L ATA F O RM A LO C A L IZ A Ç Ã O DESC RIÇ Ã O
Registo de aplicação Windows, Linux Sistema de ficheiros do Regista mensagens geradas

Serviço de Aplicações e/ou pelo seu código de
blobs de armazenamento aplicação. As mensagens
Azure podem ser geradas pelo
quadro web que escolher,
ou pelo seu código de
aplicação diretamente
utilizando o padrão padrão
de registo da sua língua.
Cada mensagem é atribuída
uma das seguintes
categorias: Crítico, Erro,
Aviso, Informação,
Depuração e Rastreio .
Pode selecionar a verbosa
que pretende que a
exploração madeireira seja
definindo o nível de
gravidade quando ativa o
registo da aplicação.
Registo de servidor web Windows Sistema de ficheiros do Raw HTTP solicita mandam
Serviço de Aplicações ou dados no formato de
blobs de armazenamento ficheiro de registo alargado
Azure W3C. Cada mensagem de
registo inclui dados como o
método HTTP, o recurso URI,
o IP do cliente, a porta
cliente, o agente utilizador, o
código de resposta, e assim
por diante.
T IP O P L ATA F O RM A LO C A L IZ A Ç Ã O DESC RIÇ Ã O
Mensagens de erro Windows Sistema de ficheiros do Cópias das páginas de erro

detalhadas Serviço de Aplicações .htm que teriam sido
enviadas para o navegador
cliente. Por razões de
segurança, as páginas de
erro detalhadas não devem
ser enviadas aos clientes em
produção, mas o Serviço de
Aplicações pode guardar a
página de erro sempre que
ocorrer um erro de aplicação
que tenha código HTTP 400
ou superior. A página pode
conter informações que
podem ajudar a determinar
por que o servidor devolve
o código de erro.
Rastreio de pedido falhado Windows Sistema de ficheiros do Informações detalhadas

Serviço de Aplicações sobre pedidos falhados,
incluindo um vestígio dos
componentes IIS utilizados
para processar o pedido e o
tempo decorrido em cada
componente. É útil se quiser
melhorar o desempenho do
site ou isolar um erro HTTP
específico. Uma pasta é
gerada para cada pedido
falhado, que contém o
ficheiro de registo XML, e a
folha de estilo XSL para
visualizar o ficheiro de
registo com.
Exploração madeireira de Windows, Linux Sistema de ficheiros do Faça logs para quando
implantação Serviço de Aplicações publica conteúdo numa
aplicação. O registo de
implantação ocorre
automaticamente e não
existem configurações
configuráveis para o registo
de implantação. Ajuda-te a
determinar porque é que
um destacamento falhou.
Por exemplo, se utilizar um
script de implementação
personalizado,poderá utilizar
o registo de implementação
para determinar porque é
que o script está a falhar.
NOTE
O Serviço de Aplicações fornece uma ferramenta dedicada de diagnóstico interativa para ajudá-lo a resolver problemas com
a sua aplicação. Para mais informações, consulte a visão geral dos diagnósticos do Serviço de Aplicações Azure.
Além disso, pode utilizar outros serviços Azure para melhorar as capacidades de registo e monitorização da sua aplicação,
como o Azure Monitor.
Ativar o registo de aplicações (Windows)
NOTE
O registo de aplicações para armazenamento de bolhas só pode utilizar contas de armazenamento na mesma região que o
Serviço de Aplicações
Para permitir o registo de aplicações para aplicações windows no portal Azure,navegue para a sua aplicação e
selecione registos do Ser viço de Aplicações.
Selecione para qualquer registo de aplicações (Sistema de Ficheiros) ou Registo de Aplicações (Blob) , ou
ambos.
A opção Filesystem é para fins de depuração temporária, e desliga-se em 12 horas. A opção Blob é para a
exploração a longo prazo, e precisa de um recipiente de armazenamento de bolhas para escrever troncos. A opção
Blob também inclui informações adicionais nas mensagens de registo, InstanceId tais como Tid a identificação
da instância EventTickCount VM de origem da mensagem de log ( ), id de linha ( ) e um carimbo de tempo mais
granular ().
NOTE
Atualmente, apenas os registos de aplicações .NET podem ser escritos no armazenamento de blob. Java, PHP, Node.js, os
registos de aplicações Python só podem ser armazenados no sistema de ficheiros do Serviço de Aplicações (sem
modificações de código para escrever registos para armazenamento externo).
Além disso, se regenerar as chavesde acesso da sua conta de armazenamento, tem de redefinir a respetiva configuração de
registo para utilizar as teclas de acesso atualizadas. Para efetuar este procedimento:
1. No separador Configurar, desloque a respetiva função de registo para desligar . Guarde a sua configuração.
2. Ative o registo na bolha da conta de armazenamento novamente. Guarde a sua configuração.
Selecione o Nível , ou o nível de detalhes para registar. O quadro seguinte mostra as categorias de registo
incluídas em cada nível:
N ÍVEL C AT EGO RIA S IN C L UÍDA S
Desativado Nenhuma
Erro Erro, Crítico
Aviso Aviso, Erro, Crítico
Informações Informação, Aviso, Erro, Crítico
Verboso Trace, Debug, Info, Warning, Error, Critical (todas as

categorias)
Quando terminar, selecione Guardar .
Ativar o registo de aplicações (Linux/Contentor)

Para permitir o registo de aplicações para aplicações Linux ou aplicações de contentores personalizadas no portal
Azure,navegue para a sua aplicação e selecione registos do Ser viço de Aplicações .
No registo de registo de aplicações, selecione Sistema de Ficheiros .
No Contingente (MB) , especifique a quota do disco para os registos de aplicação. No período de retenção
(Dias) , detete o número de dias em que os registos devem ser conservados.
Ativar o registo do servidor web

Para permitir o registo de servidores web para aplicações windows no portal Azure,navegue para a sua aplicação
e selecione registos do Ser viço de Aplicações .
Para o registo do ser vidor Web, selecione Storage para armazenar registos no armazenamento de blob ou
sistema de ficheiros para armazenar registos no sistema de ficheiros do Serviço de Aplicações.
No período de retenção (Dias) , detete o número de dias em que os registos devem ser conservados.
NOTE
Se regenerar as chavesde acesso da sua conta de armazenamento, tem de redefinir a respetiva configuração de registo para
utilizar as teclas atualizadas. Para efetuar este procedimento:
1. No separador Configurar, desloque a respetiva função de registo para desligar . Guarde a sua configuração.
2. Ative o registo na bolha da conta de armazenamento novamente. Guarde a sua configuração.
Registar erros detalhados

Para guardar a página de erro ou o pedido falhado que rastreia as aplicações do Windows no portal
Azure,navegue para a sua aplicação e selecione registos do Serviço de Aplicações .
Em registo de erro detalhado ou rastreio de pedido falhado, selecione, e depois selecione Save . On
Ambos os tipos de registos são armazenados no sistema de ficheiros do Serviço de Aplicações. São retidos até 50
erros (ficheiros/pastas). Quando o número de ficheiros HTML ultrapassa os 50, os 26 erros mais antigos são
automaticamente eliminados.
Adicione mensagens de registo no código

No seu código de aplicação, utiliza as instalações habituais de registo para enviar mensagens de registo para os
registos de aplicação. Por exemplo:
ASP.NET aplicações podem utilizar o Sistema.Diagnostics.Trace class para registar informações no registo
de diagnósticos da aplicação. Por exemplo:
System.Diagnostics.Trace.TraceError("If you're seeing this, something bad happened");
Por predefinição, ASP.NET Core utiliza o fornecedor de registo

microsoft.Extensions.Logging.AzureAppServices. Para mais informações, consulte ASP.NET Core logging
em Azure.
Transmitir registos
Antes de fazer o streaming de registos em tempo real, ative o tipo de registo que deseja. Qualquer informação
escrita para ficheiros que terminem em .txt, .log ou .htm que sejam armazenadas no diretório /LogFiles
(d:/home/logfiles) é transmitida pelo Serviço de Aplicações.
NOTE
Alguns tipos de tampão de registo escrevem para o ficheiro de registo, o que pode resultar em eventos fora de ordem no
fluxo. Por exemplo, uma entrada de registo de aplicação que ocorra quando um utilizador visita uma página pode ser
exibida no fluxo antes da entrada correspondente de registo HTTP para o pedido da página.
No portal Azure
Para transmitir registos no portal Azure,navegue para a sua aplicação e selecione log stream .
Na nuvem shell
Para transmitir registos ao vivo na Cloud Shell,utilize o seguinte comando:
az webapp log tail --name appname --resource-group myResourceGroup
Para filtrar eventos específicos, tais como erros, utilize o parâmetro --Filtro. Por exemplo:
az webapp log tail --name appname --resource-group myResourceGroup --filter Error
Para filtrar tipos de registo específicos, como http, utilize o parâmetro --Caminho. Por exemplo:
az webapp log tail --name appname --resource-group myResourceGroup --path http
No terminal local
Para transmitir registos na consola local, instale o Azure CLI e inicie sessão na sua conta. Uma vez assinado,
seguiu as instruções para Cloud Shell
Aceder a ficheiros de registo

Se configurar a opção de blobs de armazenamento Azure para um tipo de log, precisa de uma ferramenta cliente
que funcione com o Armazenamento Azure. Para mais informações, consulte ferramentas de cliente de
armazenamento azure.
Para registos armazenados no sistema de ficheiros do Serviço de Aplicações, a forma mais fácil é descarregar o
ficheiro ZIP no navegador em:
Aplicativos Linux/contentores: https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip
Aplicativos windows: https://<app-name>.scm.azurewebsites.net/api/dump
Para aplicações Linux/contentor, o ficheiro ZIP contém registos de saída de consolas tanto para o hospedeiro do
estivador como para o recipiente de estivador. Para uma aplicação com escala, o ficheiro ZIP contém um conjunto
de registos para cada instância. No sistema de ficheiros do Serviço de Aplicações, estes ficheiros de registo são o
conteúdo do diretório /home/LogFiles.
Para aplicações Windows, o ficheiro ZIP contém o conteúdo do diretório D:\Home\LogFiles no sistema de
ficheiros do Serviço de Aplicações. Tem a seguinte estrutura:
T IP O DE LO G DIRETÓ RIO DESC RIÇ Ã O
Registos de aplicação /Ficheiros de Registo/Aplicação/ Contém um ou mais ficheiros de texto.

O formato das mensagens de registo
depende do fornecedor de registo que
utiliza.
T IP O DE LO G DIRETÓ RIO DESC RIÇ Ã O
Vestígios de pedido falhados /LogFiles/W3SVC########## Contém ficheiros XML e um ficheiro

XSL. Pode ver os ficheiros XML
formatados no navegador.
Registos de erros detalhados /Ficheiros de Registo/Erros Detalhados/ Contém ficheiros de erro HTM. Pode
ver os ficheiros HTM no navegador.
Outra forma de ver os vestígios de
pedido falhados é navegar para a
página da sua aplicação no portal. A
partir do menu esquerdo, selecione
Diagnosticar e resolver
problemas, em seguida, procurar
registos de rastreio de rastreio de
pedidos falhados, em seguida, clique
no ícone para navegar e ver o traço
que deseja.
Registos de ser vidores web /LogFiles/http/RawLogs/ Contém ficheiros de texto formatados

utilizando o formato de ficheiro de
registo alargado W3C. Estas
informações podem ser lidas com um
editor de texto ou um utilitário como o
Log Parser.
O Serviço de Aplicações s-ip não
cs-version suporta os
s-computername campos ou campos.
Registos de implantação /LogFiles/Git/ e /implementações/ Contenha registos gerados pelos

processos internos de implantação,
bem como registos para
implementações git.
Envie registos para o Monitor Azure (pré-visualização)

Com a nova integração do Monitor Azure,pode criar Definições de Diagnóstico (pré-visualização) para enviar
registos para Contas de Armazenamento, Centros de Eventos e Log Analytics.
Tipos de registo suportados
A tabela que se segue mostra os tipos e descrições suportadas:
T IP O DE LO G SUP O RT E PA RA JA N EL A S SUP O RT E L IN UX ( DO C K ER) DESC RIÇ Ã O
AppServiceConsoleLogs TBA Sim Saída padrão e erro padrão
AppServiceHTTPLogs Sim Sim Registos de servidores web
AppServiceEnvironmentPlatf Sim Sim Ambiente de Serviço de

ormLogs Aplicações: escala, alterações
de configuração e registos
de estado
AppServiceAuditLogs Sim Sim Atividade de login via FTP e

Kudu
AppServiceFileAuditLogs Sim TBD Alterações de ficheiros via

FTP e Kudu
AppServiceAppLogs TBA Java SE & Tomcat Registos de aplicação
Próximos passos
Registos de consulta com monitor Azure
Como monitorizar o Serviço de Aplicações Azure
Troubleshooting Azure App Service em Estúdio Visual
Analisar registos de aplicativos no HDInsight
Obtenha eventos de recursos no Serviço de
Aplicações Azure
O Azure App Service fornece ferramentas incorporadas para monitorizar o estado e a saúde dos seus recursos. Os
eventos de recursos ajudam-no a compreender quaisquer alterações que tenham sido feitas aos recursos da sua
aplicação web subjacentes e tomem medidas necessárias. Os exemplos do evento incluem: escala de instâncias,
atualizações para definições de aplicações, reinício da aplicação web, e muito mais. Neste artigo, você aprenderá a
ver registos de atividade do Azure e permitirá que a Rede de Eventos monitorize eventos relacionados com a sua
aplicação web do App Service.
NOTE
A integração do Serviço de Aplicações com a Grelha de Eventos está em pré-visualização. Veja o anúncio para mais
detalhes.
Ver Registos de Atividade sinuosa do Azure

Os Registos de Atividade do Azure contêm eventos de recursos emitidos por operações tomadas sobre os recursos
da sua subscrição. Tanto as ações dos utilizadores nos modelos do portal Azure como do Gestor de Recursos Azure
contribuem para os eventos capturados pelo registo de Atividades.
Registos de Atividade sinuosos para detalhes do Serviço de Aplicações, tais como:
que operações foram tomadas sobre os recursos (ex: Planos de Serviço de Aplicações)
que iniciou a operação
quando a operação ocorreu
o estado da operação
valores de propriedade para ajudá-lo a pesquisar a operação
O que pode fazer com os Registos de Atividade seleção de Azure?
Os registos de atividade do Azure podem ser consultados através do portal Azure, PowerShell, REST API ou CLI.
Pode enviar os registos para uma conta de armazenamento, Event Hub e Log Analytics. Também pode analisá-los
no Power BI ou criar alertas para se manterem atualizados sobre eventos de recursos.
Ver e recuperar eventos de log da Atividade Azure.
Registos de atividade seleção para grelha de eventos

Embora os registos de Atividade sejam baseados no utilizador, existe uma nova integração da Rede de Eventos com
o App Service (pré-visualização) que regista tanto as ações dos utilizadores como os eventos automatizados. Com a
Grelha de Eventos, pode configurar um manipulador para reagir aos referidos eventos. Por exemplo, utilize o Event
Grid para acionar instantaneamente uma função sem servidor para executar imagens de análises sempre que é
adicionada uma fotografia nova a um contentor de armazenamento de blobs.
Em alternativa, pode utilizar o Event Grid com o Logic Apps para processar dados em qualquer local sem ter de
escrever código. O Event Grid liga as origens de dados e os processadores de eventos. Por exemplo, utilize o Event
Grid para acionar instantaneamente uma função sem servidor para executar imagens de análises sempre que é
adicionada uma fotografia nova a um contentor de armazenamento de blobs.
Veja as propriedades e o esquema para eventos de serviço de aplicações azure.
Próximos passos
Registos de consulta com monitor Azure
Como monitorizar o Serviço de Aplicações Azure
Troubleshooting Azure App Service em Estúdio Visual
Analisar registos de aplicativos no HDInsight
Gerir um plano de serviço de aplicações em Azure
Um plano azure App Service fornece os recursos que uma aplicação do App Service precisa de executar. Este guia
mostra como gerir um plano de Serviço de Aplicações.

TIP
Se tiver um Ambiente de Serviço de Aplicações, consulte Criar um plano de serviço de aplicações num ambiente de serviço
de aplicações.
Pode criar um plano de Serviço de Aplicações vazio, ou pode criar um plano como parte da criação de apps.
1. No portal Azure,selecione Criar um recurso .
2. Selecione New > Web App ou outro tipo de app de serviço de aplicação.
3. Configure a secção detalhes da instância antes de configurar o plano de serviço de aplicações. Definições
como Publicar e Sistemas Operativos podem alterar os níveis de preços disponíveis para o seu plano de
Serviço de Aplicações. A região determina onde é criado o seu plano de Serviço de Aplicações.
4. Na secção Plano de Serviço de Aplicações, selecione um plano existente ou crie um plano selecionando
criar novos .
5. Ao criar um plano, pode selecionar o nível de preços do novo plano. Em Sku e tamanho , selecione Alterar
tamanho para alterar o nível de preços.
Mova uma aplicação para outro plano de Serviço de Aplicações

Pode mover uma aplicação para outro plano de Serviço de Aplicações, desde que o plano de origem e o plano-alvo
estejam no mesmo grupo de recursos e região geográfica.
NOTE
O Azure implementa cada novo plano de Serviço de Aplicações numa unidade de implantação, chamada internamente de
webspace. Cada região pode ter muitos webspaces, mas a sua aplicação só pode mover-se entre planos que são criados no
mesmo espaço web. Um App Service Environment é um webspace isolado, pelo que as aplicações podem ser movidas entre
planos no mesmo App Service Environment, mas não entre planos em diferentes Ambientes de Serviço sinuoso.
Não é possível especificar o espaço web que pretende ao criar um plano, mas é possível garantir que um plano seja criado no
mesmo espaço web que um plano existente. Em resumo, todos os planos criados com o mesmo grupo de recursos e a
combinação da região são implantados no mesmo espaço web. Por exemplo, se criou um plano no grupo de recursos A e na
região B, então qualquer plano que crie posteriormente no grupo de recursos A e na região B é implantado no mesmo
espaço web. Note que os planos não podem mover webspaces depois de criados, por isso não pode mover um plano para "o
mesmo espaço web" que outro plano, transferindo-o para outro grupo de recursos.
1. No portal Azure,procure e selecione ser viços de App e selecione a app que pretende mover.
2. A partir do menu esquerdo, selecione plano de serviço de aplicações de mudança .
3. No plano de dropdown do App Ser vice, selecione um plano existente para mover a app para. A queda
mostra apenas planos que se encontram no mesmo grupo de recursos e região geográfica que o atual
plano de Serviço de Aplicações. Se não existir tal plano, permite-lhe criar um plano por defeito. Também
pode criar um novo plano manualmente selecionando criar novo .
4. Se criar um plano, pode selecionar o nível de preços do novo plano. No Nível de Preços, selecione o nível
existente para alterá-lo.
IMPORTANT
Se estiver a mover uma aplicação de um plano de nível superior para um plano de nível inferior, como de D1 para F1,
a aplicação pode perder certas capacidades no plano alvo. Por exemplo, se a sua aplicação utilizar certificados TLS/SSL,
poderá ver esta mensagem de erro:
Cannot update the site with hostname '<app_name>' because its current SSL configuration 'SNI based
SSL enabled' is not allowed in the target compute mode. Allowed SSL configuration is 'Disabled'.
5. Quando terminar, selecione OK .

Mova uma aplicação para uma região diferente
A região em que a sua aplicação funciona é a região do plano de Serviço de Aplicações em que se encontra. No
entanto, não é possível alterar a região de um plano de Serviço sinuoso. Se quiser executar a sua aplicação numa
região diferente, uma alternativa é a clonagem de aplicações. A clonagem faz uma cópia da sua aplicação num
novo ou existente plano de Serviço de Aplicações em qualquer região.
Pode encontrar a App Clone na secção Ferramentas de Desenvolvimento do menu.
IMPORTANT
A clonagem tem algumas limitações. Pode ler sobre eles na clonagem da App De Serviço de Aplicações Azure.
Escala rés-da-aplicação
Para aumentar o nível de preços de um plano de app service, consulte scale up uma app em Azure.
Para escalonar a contagem de exemplos de uma aplicação, consulte a contagem de exemplos de escala manual
mente ou automaticamente.
Eliminar um plano de serviço de aplicações

Para evitar encargos inesperados, ao eliminar a última aplicação num plano de Serviço de Aplicações, o App
Service também elimina o plano por padrão. Se optar por manter o plano, deve mudar o plano para free tier para
não ser cobrado.
IMPORTANT
Os planos do Serviço de Aplicações que não têm aplicações associadas ainda incorrem em encargos porque continuam a
reservar as instâncias de VM configuradas.
Passos seguintes
Aumentar verticalmente uma aplicação no Azure
Efetuar cópia de segurança da sua aplicação no
Azure
A funcionalidade de Backup e Restauro no Azure App Service permite-lhe criar facilmente cópias de segurança de
aplicações manualmente ou em horário. Pode configurar as cópias de segurança para serem mantidas até um
tempo indefinido. Pode restaurar a aplicação para uma imagem instantânea de um estado anterior,
sobressacando a aplicação existente ou restaurando para outra aplicação.
Para obter informações sobre a restauração de uma aplicação a partir de cópia de segurança, consulte Restaurar
uma aplicação no Azure.
O que é apoiado
O Serviço de Aplicações pode fazer o back up das seguintes informações para uma conta de armazenamento
Azure e um contentor que configuraram a sua aplicação para utilizar.
Configuração de aplicações
Conteúdo do ficheiro
Base de dados ligada à sua aplicação
As seguintes soluções de base de dados são suportadas com recurso de backup:
Base de Dados SQL
Base de Dados do Azure para MySQL
Base de Dados do Azure para PostgreSQL
MySQL in-app
NOTE
Cada cópia de segurança é uma cópia completa offline da sua aplicação, não uma atualização incremental.
Requisitos e restrições
A funcionalidade de Backup e Restauro requer que o plano de Serviço de Aplicações esteja no nível Standard,
Premium ou Isolado. Para obter mais informações sobre o escalonamento do seu plano de Serviço de
Aplicações para utilizar um nível mais elevado, consulte Scale up uma aplicação em Azure. Os níveis premium
e isolado permitem um maior número de back ups diários do que o nível Standard.
Precisa de uma conta de armazenamento Azure e de um recipiente na mesma subscrição que a aplicação que
pretende fazer. Para obter mais informações sobre as contas de armazenamento da Azure, consulte a visão
geral da conta de armazenamento Azure.
As cópias de segurança podem chegar a 10 GB de conteúdo de aplicações e bases de dados. Se o tamanho da
cópia de segurança exceder este limite, obtém-se um erro.
As cópias de segurança da Base de Dados Azure ativada por TLS para o MySQL não são suportadas. Se um
backup estiver configurado, receberá cópias de segurança falhadas.
Não são suportadas cópias de segurança da Base de Dados Azure ativada por TLS para PostgreSQL. Se um
backup estiver configurado, receberá cópias de segurança falhadas.
As bases de dados MySQL in-app são automaticamente apoiadas sem qualquer configuração. Se escamar
configurações manuais para bases de dados MySQL na aplicação, como adicionar cordas de ligação, as cópias
de segurança podem não funcionar corretamente.
A utilização de uma conta de armazenamento ativada por firewall, uma vez que o destino das suas cópias de
segurança não é suportado. Se um backup estiver configurado, receberá cópias de segurança falhadas.
Criar uma cópia de segurança manual

1. No portal Azure,navegue para a página da sua aplicação, selecione Backups . A página 'Backups' é
apresentada.
NOTE
Se vir a seguinte mensagem, clique nela para atualizar o seu plano de Serviço de Aplicações antes de poder
proceder com cópias de segurança. Para obter mais informações, consulte Scale up uma aplicação em Azure.
2. Na página 'Backup', o backup não está configurado. Clique aqui para configurar a cópia de
segurança para a sua aplicação.
3. Na página de Configuração de Cópia de Segurança, clique em Armazenamento não configurado

para configurar uma conta de armazenamento.
4. Escolha o seu destino de reserva selecionando uma Conta de Armazenamento e Um Recipiente. A
conta de armazenamento deve pertencer à mesma subscrição que a aplicação que pretende fazer. Se
desejar, pode criar uma nova conta de armazenamento ou um novo recipiente nas respetivas páginas.
Quando terminar, clique em Select .
5. Na página de Configuração de Cópia de Segurança que ainda está aberta, pode configurar a Base de
Dados de Backup, em seguida, selecione as bases de dados que pretende incluir nas cópias de segurança
(base de dados SQL ou MySQL), em seguida, clique em OK .
NOTE
Para que uma base de dados apareça nesta lista, a sua cadeia de ligação deve existir na secção de cordas de
Ligação da página de definições de aplicação para a sua aplicação.
As bases de dados MySQL in-app são automaticamente apoiadas sem qualquer configuração. Se escamar
configurações manuais para bases de dados MySQL na aplicação, como adicionar cordas de ligação, as cópias de
segurança podem não funcionar corretamente.
6. Na página de Configuração de Cópia de Segurança, clique em Guardar .

7. Na página 'Backups', clique em Backup .
Vê uma mensagem de progresso durante o processo de backup.
Uma vez configurada a conta de armazenamento e o recipiente, pode iniciar uma cópia de segurança manual a
qualquer momento.
Configurar backups automatizados

1. Na página de Configuração de Cópia de Segurança, desatado a cópia de segurança programada
para On .
2. Configure o horário de reserva conforme desejado e selecione OK .

Configurar backups parciais
Às vezes não queres fazer o back-up da tua aplicação. Eis alguns exemplos:
Configura cópias de segurança semanais da sua aplicação que contém conteúdo estático que nunca muda,
como publicações de blogues antigas ou imagens.
A sua aplicação tem mais de 10 GB de conteúdo (é o valor máximo que pode fazer de cada vez).
Não vai querer fazer o registo.
As cópias de segurança parciais permitem-lhe escolher exatamente quais os ficheiros que pretende fazer cópias
de segurança.
NOTE
As bases de dados individuais na cópia de segurança podem ser de 4GB no máximo, mas o tamanho máximo total da cópia
de segurança é de 10GB
Exclua ficheiros da sua cópia de segurança

Suponha que tem uma aplicação que contém ficheiros de registo e imagens estáticas que foram cópias de
segurança uma vez e não vão mudar. Nesses casos, pode excluir que as pastas e ficheiros sejam armazenados nas
suas futuras cópias de segurança. Para excluir ficheiros e pastas das suas cópias de segurança, crie um
_backup.filter ficheiro na pasta da sua D:\home\site\wwwroot aplicação. Especifique a lista de ficheiros e pastas
que pretende excluir neste ficheiro.
Pode aceder aos seus ficheiros navegando para https://<app-name>.scm.azurewebsites.net/DebugConsole . Se
solicitado, inscreva-se na sua conta Azure.
Identifique as pastas que pretende excluir das suas cópias de segurança. Por exemplo, pretende filtrar a pasta e os
ficheiros realçados.
Crie um ficheiro chamado _backup.filter e coloque a lista anterior no ficheiro, mas remova D:\home . Listar um
diretório ou ficheiro por linha. Assim, o conteúdo do ficheiro deve ser:
\site\wwwroot\Images\brand.png
\site\wwwroot\Images\2014
\site\wwwroot\Images\2013
Faça _backup.filter o upload do ficheiro para o D:\home\site\wwwroot\ diretório do seu site utilizando ftp ou
qualquer outro método. Se desejar, pode criar o ficheiro diretamente utilizando o Kudu DebugConsole e inserir o
conteúdo lá.
Execute cópias de segurança da mesma forma que normalmente o faria, manualmente ou automaticamente.
Agora, quaisquer ficheiros e pastas especificadas _backup.filter estão excluídos das futuras cópias de segurança
programadas ou iniciadas manualmente.
NOTE
Restaura cópias de segurança parciais do seu site da mesma forma que restauraria uma cópia de segurança regular. O
processo de restauro faz a coisa certa.
Quando uma cópia de segurança completa é restaurada, todo o conteúdo do site é substituído por tudo o que estiver na
cópia de segurança. Se um ficheiro estiver no site, mas não na cópia de segurança, é apagado. Mas quando uma cópia de
segurança parcial é restaurada, qualquer conteúdo que esteja localizado num dos diretórios da lista negra, ou em qualquer
ficheiro na lista negra, é deixado como está.
Como as cópias de segurança são armazenadas

Depois de ter feito uma ou mais cópias de segurança para a sua aplicação, as cópias de segurança estão visíveis
na página de Contentores da sua conta de armazenamento e na sua aplicação. Na conta de armazenamento,
cada cópia de segurança consiste num .zip ficheiro que contém os dados de backup e um ficheiro que contém
um manifesto do conteúdo do .xml .zip ficheiro. Pode desapertar e navegar nestes ficheiros se quiser aceder
às suas cópias de segurança sem realmente realizar uma restauração de aplicações.
A cópia de segurança da base de dados da aplicação é armazenada na raiz do ficheiro .zip. Para uma base de
dados SQL, este é um ficheiro BACPAC (sem extensão de ficheiro) e pode ser importado. Para criar uma base de
dados SQL baseada na exportação BACPAC, consulte importar um ficheiro BACPAC para criar uma nova base de
dados de utilizadores.
WARNING
Alterar qualquer um dos ficheiros do seu contentor de backups do seu website pode fazer com que a cópia de segurança
se torne inválida e, portanto, não seja restauradora.

Pode automatizar a gestão de backup com scripts, utilizando o Azure CLI ou o Azure PowerShell.
Para amostras, consulte:
Exemplos da CLI do Azure
Amostras Azure PowerShell
Passos Seguintes
Para obter informações sobre a restauração de uma aplicação a partir de uma cópia de segurança, consulte
Restaurar uma aplicação no Azure.
Restaurar uma aplicação no Azure
Este artigo mostra-lhe como restaurar uma aplicação no Azure App Service que já fez o backback (ver Back up a
sua aplicação em Azure). Pode restaurar a sua aplicação com as suas bases de dados ligadas a pedido para um
estado anterior, ou criar uma nova aplicação com base numa das cópias de segurança da sua aplicação original. O
Azure App Service suporta as seguintes bases de dados para cópia de segurança e restauro:
Base de Dados SQL
MySQL in-app
Restaurar de backups está disponível para aplicações em execução em nível Standard e Premium. Para obter
informações sobre o dimensionamento da sua aplicação, consulte Scale up uma aplicação no Azure. O nível
premium permite que um maior número de backups diários seja realizado do que o nível Standard.
Restaurar uma aplicação a partir de uma cópia de segurança existente

1. Na página Definições da sua aplicação no portal Azure, clique em Backups para exibir a página
Backups. Em seguida, clique em Restaurar .
2. Na página Restaurar, primeiro selecione a fonte de reserva.
A opção de backup da App mostra-lhe todas as cópias de segurança existentes da aplicação atual, e pode
facilmente selecionar uma. A opção Armazenamento permite selecionar qualquer ficheiro ZIP de reserva
de qualquer conta e contentor de Armazenamento Azure existentes na sua subscrição. Se estiver a tentar
restaurar uma cópia de segurança de outra aplicação, utilize a opção Armazenamento.
3. Em seguida, especifique o destino para a restauração da aplicação no destino Restaurar .
WARNING
Se escolher A Sobreescrita, todos os dados existentes na sua aplicação atual são apagados e substituídos. Antes
de clicar em OK, certifique-se de que é exatamente o que quer fazer.
WARNING
Se o Serviço de Aplicações estiver a escrever dados para a base de dados enquanto os está a restaurar, pode
resultar em sintomas como violação da CHAVE PRIMÁRIA e perda de dados. Sugere-se que pare o Serviço de
Aplicações primeiro antes de começar a restaurar a base de dados.
Pode selecionar a App Existente para restaurar a cópia de segurança da aplicação para outra aplicação no
mesmo grupo de recursos. Antes de utilizar esta opção, já deveria ter criado outra aplicação no seu grupo
de recursos com a configuração da base de dados espelhada para a definida na cópia de segurança da
aplicação. Também pode Criar uma nova aplicação para restaurar o seu conteúdo.
4. Clique em OK .
Faça o download ou apague uma cópia de segurança de uma conta de

armazenamento
1. A partir da página principal de Navegação do portal Azure, selecione contas de Armazenamento. É
apresentada uma lista das suas contas de armazenamento existentes.
2. Selecione a conta de armazenamento que contém a cópia de segurança que pretende descarregar ou
eliminar. A página da conta de armazenamento é apresentada.
3. Na página da conta de armazenamento, selecione o recipiente que deseja
4. Selecione ficheiro de reserva que pretende descarregar ou eliminar.
5. Clique em Baixar ou Apagar dependendo do que pretende fazer.
Monitorize uma operação de restauro

Para ver detalhes sobre o sucesso ou falha da operação de restauro da aplicação, navegue para a página de
Registo de Atividades no portal Azure.
Desloque-se para baixo para encontrar a operação de restauro desejada e clique para selecioná-la.
A página de detalhes mostra as informações disponíveis relacionadas com a operação de restauro.

Pode automatizar a gestão de backup com scripts, utilizando o Azure CLI ou o Azure PowerShell.
Para amostras, consulte:
Exemplos da CLI do Azure
Amostras Azure PowerShell
Restaurar uma aplicação em Azure a partir de um
instantâneo
Este artigo mostra-lhe como restaurar uma aplicação no Azure App Service a partir de um instantâneo. Pode
restaurar a sua aplicação para um estado anterior, com base numa das fotos da sua aplicação. Não é necessário
ativar a cópia de segurança de instantâneos, a plataforma guarda automaticamente uma imagem instantânea de
todas as aplicações para fins de recuperação de dados.
Os instantâneos são cópias de sombra incremental, e oferecem várias vantagens sobre cópias de segurança
regulares:
Não há erros de cópia de ficheiros devido a fechaduras de ficheiros.
Sem limitação do tamanho do armazenamento.
Não é necessária qualquer configuração.
Restaurar a partir de instantâneos está disponível para aplicações em nível Premium ou superior. Para obter
informações sobre o dimensionamento da sua aplicação, consulte Scale up uma aplicação no Azure.
Limitações
A funcionalidade encontra-se atualmente em pré-visualização.
Só pode restaurar a mesma aplicação ou uma ranhura pertencente a essa aplicação.
O Serviço de Aplicações para a aplicação alvo ou a ranhura de destino durante a restauração.
O Serviço de Aplicações mantém três meses de instantâneos para fins de recuperação de dados da plataforma.
Só pode restaurar as fotos nos últimos 30 dias.
Os serviços de aplicações que estão a funcionar num App Service Environment não suportam instantâneos.
Restaurar uma aplicação a partir de um instantâneo

1. Na página Definições da sua aplicação no portal Azure,clique em Backups para exibir a página Backups.
Em seguida, clique em Restaurar sob a secção Snapshot(Pré-visualização).
2. Na página Restaurar, selecione o instantâneo para restaurar.

3. Especifique o destino para a restauração da aplicação no destino Restaurar .
WARNING
Se escolher a Over write , todos os dados existentes no sistema de ficheiros atual da sua aplicação são apagados e
substituídos. Antes de clicar em OK, certifique-se de que é o que quer fazer.
NOTE
Devido às limitações técnicas atuais, só é possível restaurar as aplicações na mesma unidade de escala. Esta limitação
será removida numa futura versão.
Pode selecionar a App Existente para restaurar uma ranhura. Antes de utilizar esta opção, já deveria ter
criado uma ranhura na sua aplicação.
4. Pode optar por restaurar a configuração do seu site.
5. Clique em OK .
Clonagem de aplicativos de aplicativo sinuoso
usando powershell
NOTE
Com o lançamento da versão 1.1.1.0 do Microsoft Azure PowerShell, foi adicionada uma nova opção que
New-AzWebApp permite clonar uma aplicação app Service existente para uma aplicação recém-criada numa região
diferente ou na mesma região. Esta opção permite que os clientes implementem uma série de aplicações em
diferentes regiões de forma rápida e fácil.
A clonagem de aplicativos é suportada para planos de serviço de aplicações Standard, Premium, Premium V2 e
Isolados. A nova funcionalidade utiliza as mesmas limitações que a funcionalidade de backup de serviço de
aplicação, consulte o Back up a uma aplicação no Azure App Service.
Clonagem de uma app existente

Cenário: Uma aplicação existente na região centro-sul dos EUA, e você quer clonar os conteúdos para uma nova
app na região do Centro-Norte dos EUA. Pode ser realizado utilizando a versão Do Gestor de Recursos Azure do
cmdlet PowerShell para criar uma nova app com a opção. -SourceWebApp
Conhecendo o nome do grupo de recursos que contém a aplicação fonte, pode utilizar o source-webapp seguinte
comando PowerShell para obter as informações da aplicação de origem (neste caso nomeado):
$srcapp = Get-AzWebApp -ResourceGroupName SourceAzureResourceGroup -Name source-webapp
Para criar um novo Plano de New-AzAppServicePlan Serviço de Aplicações, pode usar o comando como no
exemplo seguinte
New-AzAppServicePlan -Location "North Central US" -ResourceGroupName DestinationAzureResourceGroup -Name

DestinationAppServicePlan -Tier Standard
Utilizando New-AzWebApp o comando, pode criar a nova app na região centro-norte dos EUA e ligá-la a um Plano
de Serviço de Aplicações existente. Além disso, pode utilizar o mesmo grupo de recursos que a aplicação fonte, ou
definir um novo grupo de recursos, como mostra o seguinte comando:
$destapp = New-AzWebApp -ResourceGroupName DestinationAzureResourceGroup -Name dest-webapp -Location "North

Central US" -AppServicePlan DestinationAppServicePlan -SourceWebApp $srcapp
Para clonar uma aplicação existente, incluindo todas as IncludeSourceWebAppSlots ranhuras de implementação
associadas, é necessário utilizar o parâmetro. Note que IncludeSourceWebAppSlots o parâmetro só é suportado
para clonagem de uma aplicação inteira, incluindo todas as suas ranhuras. O seguinte comando PowerShell
demonstra a utilização New-AzWebApp desse parâmetro com o comando:

Central US" -AppServicePlan DestinationAppServicePlan -SourceWebApp $srcapp -IncludeSourceWebAppSlots
Para clonar uma aplicação existente dentro da mesma região, é necessário criar um novo grupo de recursos e um
novo plano de serviço de aplicações na mesma região e, em seguida, usar o seguinte comando PowerShell para
clonar a app:
$destapp = New-AzWebApp -ResourceGroupName NewAzureResourceGroup -Name dest-webapp -Location "South Central

US" -AppServicePlan NewAppServicePlan -SourceWebApp $srcapp
Clonagem de uma app existente para um ambiente de serviço de

aplicações
Cenário: Uma aplicação existente na região centro-sul dos EUA, e você quer clonar os conteúdos para uma nova
app para um App Service Environment (ASE) existente.
Conhecendo o nome do grupo de recursos que contém a aplicação fonte, pode utilizar o source-webapp seguinte
comando PowerShell para obter as informações da aplicação de origem (neste caso nomeado):
$srcapp = Get-AzWebApp -ResourceGroupName SourceAzureResourceGroup -Name source-webapp
Conhecendo o nome da ASE e o nome de grupo de recursos a que a ASE pertence, pode criar a nova app na ASE
existente, como mostra o seguinte comando:

Central US" -AppServicePlan DestinationAppServicePlan -ASEName DestinationASE -ASEResourceGroupName
DestinationASEResourceGroupName -SourceWebApp $srcapp
O Location parâmetro é necessário devido à razão do legado, mas é ignorado quando se cria a aplicação numa
ASE.
Clonagem de uma ranhura de app existente

Cenário: Pretende clonar uma ranhura de implementação existente de uma aplicação para uma nova app ou uma
nova ranhura. A nova aplicação pode estar na mesma região que a ranhura original da aplicação ou numa região
diferente.
Conhecendo o nome do grupo de recursos que contém a aplicação fonte, pode utilizar o seguinte source-appslot
comando source-app PowerShell para obter as informações da aplicação de origem (neste caso nomeado )
ligadas a:
$srcappslot = Get-AzWebAppSlot -ResourceGroupName SourceAzureResourceGroup -Name source-app -Slot source-

appslot
O seguinte comando demonstra a criação de um clone da app de origem para uma nova aplicação:
$destapp = New-AzWebApp -ResourceGroupName DestinationAzureResourceGroup -Name dest-app -Location "North

Central US" -AppServicePlan DestinationAppServicePlan -SourceWebApp $srcappslot
Configurar o Gestor de Tráfego ao clonar uma aplicação
Criar aplicações multi-regiões e configurar o Azure Traffic Manager para direcionar o tráfego para todas estas
aplicações, é um cenário importante para garantir que as aplicações dos clientes estão altamente disponíveis. Ao
clonar uma aplicação existente, tem a opção de ligar ambas as aplicações a um novo perfil de gestor de tráfego ou
a uma existente. Apenas a versão do Gestor de Recursos Azure do Traffic Manager é suportada.
Criar um novo perfil de Gestor de Tráfego ao clonar uma app
Cenário: Pretende clonar uma aplicação para outra região, ao mesmo tempo que configura um perfil de gestor de
tráfego do Gestor de Recursos Azure que inclui ambas as aplicações. O seguinte comando demonstra a criação de
um clone da app de origem para uma nova aplicação enquanto configura um novo perfil do Traffic Manager:
$destapp = New-AzWebApp -ResourceGroupName DestinationAzureResourceGroup -Name dest-webapp -Location "South

Central US" -AppServicePlan DestinationAppServicePlan -SourceWebApp $srcapp -TrafficManagerProfileName
newTrafficManagerProfile
Adicionar nova app clonada a um perfil de Gestor de Tráfego existente

Cenário: Já tem um perfil de Gestor de Recursos Azure e quer adicionar ambas as aplicações como pontos finais.
Para isso, primeiro é necessário montar o perfil de perfil do gestor de tráfego existente. Você precisa do ID de
subscrição, o nome do grupo de recursos, e o nome de perfil do gestor de tráfego existente.
$TMProfileID = "/subscriptions/<Your subscription ID goes here>/resourceGroups/<Your resource group name goes

here>/providers/Microsoft.TrafficManagerProfiles/ExistingTrafficManagerProfileName"
Depois de ter o ID de manjedoura de tráfego, o seguinte comando demonstra a criação de um clone da app de
origem para uma nova aplicação, adicionando-as a um perfil de Traffic Manager existente:
$destapp = New-AzWebApp -ResourceGroupName <Resource group name> -Name dest-webapp -Location "South Central
US" -AppServicePlan DestinationAppServicePlan -SourceWebApp $srcapp -TrafficManagerProfileId $TMProfileID
Restrições atuais
Aqui estão as restrições conhecidas da clonagem de apps:
As definições de escala automática não são clonadas
As definições de horário de backup não são clonadas
As definições vNET não são clonadas
App Insights não são automaticamente configurados na aplicação de destino
As configurações easy Auth não são clonadas
Extensão de Kudu não são clonados
As regras do TIP não são clonadas
O conteúdo da base de dados não é clonado
Endereços IP de saída mudam se clonagem para uma unidade de escala diferente
Não disponível para Aplicativos Linux
Referências
Clonagem de serviço sinuoso
Back up uma app no Azure App Service
Suporte do Gestor de Recursos Azure para pré-visualização do Gestor de Tráfego do Azure
Introdução ao Ambiente do Serviço de Aplicações
Utilizar o Azure PowerShell com o Azure Resource Manager
Restaurar a aplicação do Serviço de Aplicações
eliminada com o PowerShell
Se por acaso eliminar acidentalmente a sua aplicação no Azure App Service, pode restaurá-la utilizando os
comandos do módulo Az PowerShell.
NOTE
As aplicações eliminadas são expurgadas do sistema 30 dias após a eliminação inicial. Uma vez que uma aplicação foi
purgada, não pode ser recuperada.
Re-registrar fornecedor de recursos do Serviço de Aplicações

Alguns clientes podem deparar-se com um problema em que a recuperação da lista de aplicações eliminadas falha.
Para resolver o problema, executar o seguinte comando:
Register-AzResourceProvider -ProviderNamespace "Microsoft.Web"
Lista de aplicativos eliminados

Para obter a recolha de aplicações eliminadas, pode usar Get-AzDeletedWebApp .
Para mais detalhes sobre uma aplicação específica eliminada, pode utilizar:
Get-AzDeletedWebApp -Name <your_deleted_app> -Location <your_deleted_app_location>
As informações detalhadas incluem:

DeletedSiteId : Identificador exclusivo para a aplicação, usado para cenários onde várias aplicações com o
mesmo nome foram eliminadas
SubscriçãoID : Assinatura que contém o recurso eliminado
Localização : Localização da aplicação original
Nome do Grupo de Recursos : Nome do grupo de recursos original
Nome : Nome da aplicação original.
Ranhura : o nome da ranhura.
Tempo de Eliminação : Quando a aplicação foi eliminada
Restaurar app eliminada

NOTE
Restore-AzDeletedWebApp não é suportado para aplicações de função.
Uma vez identificada a aplicação que pretende restaurar, pode restaurá-la Restore-AzDeletedWebApp utilizando.
Restore-AzDeletedWebApp -ResourceGroupName <my_rg> -Name <my_app> -TargetAppServicePlanName <my_asp>
NOTE
As ranhuras de implementação não são restauradas como parte da sua aplicação. Se precisar de restaurar uma ranhura de
paragem, utilize a -Slot <slot-name> bandeira.
As entradas para o comando são:

Grupo de Recursos : Grupo de recursos-alvo onde a app será restaurada
Nome : Nome para a aplicação, deve ser globalmente único.
TargetAppSer vicePlanName : Plano de Serviço de Aplicações ligado à app
Por Restore-AzDeletedWebApp predefinição, restaurará tanto a configuração da sua aplicação como qualquer
conteúdo. Se quiser apenas restaurar o conteúdo, utilize a -RestoreContentOnly bandeira com este comando.
NOTE
Se a aplicação foi hospedada e depois eliminada de um Ambiente de Serviço de Aplicações, então só pode ser restaurada se o
ambiente de serviço de aplicações correspondente ainda existir.
Pode encontrar aqui a referência completa do comando: Restore-AzDeletedWebApp.

Mova uma app de Serviço de Aplicações para outra
região
Este artigo descreve como mover recursos do Serviço app para uma região azure diferente. Pode transferir os seus
recursos para outra região por uma série de razões. Por exemplo, aproveitar uma nova região do Azure,
implementar recursos ou serviços disponíveis apenas em regiões específicas, para satisfazer os requisitos de
política interna e governação, ou em resposta aos requisitos de planeamento de capacidades.
Os recursos do Serviço de Aplicações são específicos da região e não podem ser movidos por regiões. Você deve
criar uma cópia dos seus recursos de Serviço de Aplicações existentes na região alvo, mover o seu conteúdo para a
nova app. Se a sua aplicação de origem utilizar um domínio personalizado, pode migrar para a nova aplicação na
região alvo quando terminar.
Para facilitar a cópia da sua aplicação, pode clonar uma aplicação individual do App Service num plano de Serviço
de Aplicações noutra região, mas tem limitações– especialmente que não suporta aplicações Linux.
Pré-requisitos
Certifique-se de que a aplicação App Service está na região do Azure, da qual pretende mover-se.
Certifique-se de que a região alvo suporta o Serviço de Aplicações e qualquer serviço relacionado, cujos
recursos pretende mover.
Preparação
Identifique todos os recursos do Serviço de Aplicações que está a utilizar. Por exemplo:
Aplicações do Serviço de Aplicações
Planos do Serviço de Aplicações
Blocos de implementação
Domínios personalizados adquiridos em Azure
Certificados SSL
Integração da Rede Virtual Azure
Ligações híbridas.
Identidades geridas
Definições de backup
Certos recursos, tais como certificados importados ou ligações híbridas, contêm integração com outros serviços
Azure. Para obter informações sobre como movimentar esses recursos através das regiões, consulte a
documentação para os respetivos serviços.
Mover
1. Crie um back up da aplicação de origem.
2. Crie uma aplicação num novo plano de Serviço de Aplicações, na região alvo.
3. Restaurar a parte de trás na app alvo
4. Se utilizar um domínio personalizado, ligue-o preventivamente à aplicação alvo e awverify. ative o domínio na
aplicação alvo.
5. Configure tudo o resto na sua aplicação alvo para ser o mesmo que a aplicação de origem e verifique a sua
configuração.
6. Quando estiver pronto para que o domínio personalizado aponte para a aplicação alvo, remape o nome de
domínio.
Limpar os recursos de origem

Elimine a aplicação de origem e o plano de serviço de aplicações. Um plano de Serviço de Aplicações no nível não
gratuito tem uma taxa, mesmo que nenhuma aplicação esteja a funcionar nele.
Passos seguintes
Clonagem de aplicativos de aplicativo sinuoso usando powershell
Move resources to a new resource group or
subscription (Mover recursos para um grupo de
recursos ou uma subscrição nova)
Este artigo mostra-lhe como mover os recursos do Azure para outra subscrição do Azure ou outro grupo de
recursos sob a mesma subscrição. Para mover recursos, pode utilizar o portal do Azure, o Azure PowerShell, a CLI
do Azure ou a API REST.
Tanto o grupo de origem como o grupo alvo estão bloqueados durante a operação de movimento. As operações de
escrita e exclusão são bloqueadas nos grupos de recursos até que o movimento esteja concluído. Este bloqueio
significa que não pode adicionar, atualizar ou eliminar recursos nos grupos de recursos. Não significa que os
recursos estão congelados. Por exemplo, se mover um Servidor SQL e a sua base de dados para um novo grupo de
recursos, uma aplicação que utiliza a base de dados não experimenta tempo de inatividade. Ainda pode ler e
escrever para a base de dados. O cadeado pode durar um máximo de quatro horas, mas a maioria dos
movimentos completam-se em muito menos tempo.
Mover um recurso apenas o move para um grupo de recursos ou uma subscrição novos. Não altera a localização
do recurso.
Lista de verificação antes de mover recursos

Antes de mover um recurso, é necessário realizar alguns passos importantes. Ao confirmar estas condições, pode
evitar erros.
1. Os recursos que quer mover devem apoiar a operação de movimento. Para obter uma lista dos recursos de
apoio, consulte o apoio da operação Move para recursos.
2. Alguns serviços têm limitações ou requisitos específicos ao mover recursos. Se estiver a mover algum dos
seguintes serviços, verifique essa orientação antes de se deslocar.
Os Serviços de Aplicações movem orientação
Serviços Azure DevOps movem orientação
Modelo clássico de implementação move orientação - Classic Compute, Classic Storage, Classic Virtual
Networks e Cloud Services
Orientação de movimento em rede
Serviços de Recuperação movem orientação
Máquinas Virtuais movem orientação
3. As assinaturas de origem e destino devem estar ativas. Se tiver dificuldade em permitir uma conta que
tenha sido desativada, crie um pedidode apoio Azure . Selecione Gestão de Assinatura para o tipo de
problema.
4. As assinaturas de origem e destino devem existir dentro do mesmo inquilino azure Ative Directory. Para
verificar se ambas as subscrições têm o mesmo ID de inquilino, utilize o Azure PowerShell ou o Azure CLI.
Para a Azure PowerShell, utilize:
(Get-AzSubscription -SubscriptionName <your-source-subscription>).TenantId

(Get-AzSubscription -SubscriptionName <your-destination-subscription>).TenantId
Para a CLI do Azure, utilize:
az account show --subscription <your-source-subscription> --query tenantId

az account show --subscription <your-destination-subscription> --query tenantId
Se as iDs de inquilino para as assinaturas de origem e destino não forem as mesmas, utilize os seguintes
métodos para conciliar as iDs dos inquilinos:
Transferir a propriedade de uma subscrição do Azure para outra conta
Como associar ou adicionar uma subscrição do Azure ao Azure Active Directory
5. A subscrição de destino tem de estar registada no fornecedor de recursos do recurso a ser movido. Caso
contrário, recebe um erro indicando que a subscrição não está registada para um tipo de recurso .
Pode ver este erro ao mover um recurso para uma nova subscrição, mas essa subscrição nunca foi utilizada
com esse tipo de recursos.
Para a PowerShell, utilize os seguintes comandos para obter o estado de registo:
Set-AzContext -Subscription <destination-subscription-name-or-id>

Get-AzResourceProvider -ListAvailable | Select-Object ProviderNamespace, RegistrationState
Para registar um fornecedor de recursos, utilize:
Register-AzResourceProvider -ProviderNamespace Microsoft.Batch
Para o Azure CLI, utilize os seguintes comandos para obter o estado de registo:
az account set -s <destination-subscription-name-or-id>

az provider list --query "[].{Provider:namespace, Status:registrationState}" --out table
Para registar um fornecedor de recursos, utilize:
az provider register --namespace Microsoft.Batch
6. A conta que movimenta os recursos deve ter, pelo menos, as seguintes permissões:
Microsoft.Recursos/subscrições/recursosGroups/moveResources/action on the source resource
group.
Microsoft.Recursos/subscrições/recursosGroups/write no grupo de recursos de destino.
7. Antes de mover os recursos, verifique as quotas de subscrição para a subscrição para a qual está a mover os
recursos. Se mover os recursos significa que a subscrição excederá os seus limites, terá de rever se pode
solicitar um aumento da quota. Para uma lista de limites e como solicitar um aumento, consulte os limites
de subscrição e serviço do Azure, quotas e constrangimentos.
8. Para uma mudança através das assinaturas, o recurso e os seus recursos dependentes devem
estar localizados no mesmo grupo de recursos e devem ser movidos em conjunto. Por exemplo,
um VM com discos geridos exigiria que o VM e os discos geridos fossem movidos em conjunto, juntamente
com outros recursos dependentes.
Se está a mover um recurso para uma nova subscrição, verifique se o recurso tem algum recurso
dependente e se estão localizados no mesmo grupo de recursos. Se os recursos não estiverem no mesmo
grupo de recursos, verifique se os recursos podem ser consolidados no mesmo grupo de recursos. Em caso
afirmativo, traga todos estes recursos para o mesmo grupo de recursos, utilizando uma operação de
movimento através de grupos de recursos.
Para mais informações, consulte Cenário para se deslocar através de subscrições.
Cenário para mover entre subscrições

Mover recursos de uma subscrição para outra é um processo em três etapas:
Para fins de ilustração, temos apenas um recurso dependente.

Passo 1: Se os recursos dependentes forem distribuídos por diferentes grupos de recursos, primeiro movê-los
para um grupo de recursos.
Passo 2: Mover o recurso e os recursos dependentes da subscrição de origem para a subscrição-alvo.
Passo 3: Opcionalmente, redistribua os recursos dependentes para diferentes grupos de recursos dentro da
subscrição-alvo.
Validar movimento
A operação de movimento validado permite testar o seu cenário de movimento sem realmente mover os recursos.
Utilize esta operação para verificar se o movimento terá sucesso. A validação é automaticamente chamada quando
envia um pedido de mudança. Utilize esta operação apenas quando necessitar de determinar os resultados. Para
executar esta operação, precisa do:
nome do grupo de recursos de origem
identificação de recursos do grupo de recursos-alvo
identificação de recursos de cada recurso para mover
o sinal de acesso para a sua conta
Envie o seguinte pedido:
POST https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<source-
group>/validateMoveResources?api-version=2019-05-10
Authorization: Bearer <access-token>
Content-type: application/json
Com um corpo de pedido:
{
"resources": ["<resource-id-1>", "<resource-id-2>"],
"targetResourceGroup": "/subscriptions/<subscription-id>/resourceGroups/<target-group>"
}
Se o pedido for forjado corretamente, a operação devolve:
Response Code: 202

cache-control: no-cache
pragma: no-cache
expires: -1
location: https://management.azure.com/subscriptions/<subscription-id>/operationresults/<operation-id>?api-
version=2018-02-01
retry-after: 15
...
O código de estado de 202 indica que o pedido de validação foi aceite, mas ainda não determinou se a operação de
mudança será bem sucedida. O location valor contém um URL que utiliza para verificar o estado da operação de
longa duração.
Para verificar o estado, envie o seguinte pedido:
GET <location-url>
Authorization: Bearer <access-token>
Enquanto a operação ainda estiver em curso, continua a receber o código de estado de 202. Aguarde o número
retry-after de segundos indicado si no valor antes de tentar novamente. Se a operação de movimento validar
com sucesso, receberá o código de estado 204. Se a validação do movimento falhar, recebe uma mensagem de
erro, como:
{"error":{"code":"ResourceMoveProviderValidationFailed","message":"<message>"...}}
Utilizar o portal
Para movimentar recursos, selecione o grupo de recursos com esses recursos e, em seguida, selecione o botão
Mover.
Selecione se está a mover os recursos para um novo grupo de recursos ou para uma nova subscrição.
Selecione os recursos para mover e o grupo de recursos de destino. Reconheça que precisa atualizar scripts para
estes recursos e selecione OK . Se selecionou o ícone de subscrição de edição no passo anterior, também deve
selecionar a subscrição de destino.
Em Notificações, vê que a operação de movimento está a decorrer.
Quando estiver concluído, é notificado do resultado.
Se tiver um erro, consulte a Troubleshoot movendo os recursos do Azure para um novo grupo de recursos ou
subscrição.
Para mover os recursos existentes para outro grupo de recursos ou subscrição, utilize o comando Move-
AzResource. O exemplo que se segue mostra como transferir vários recursos para um novo grupo de recursos.
$webapp = Get-AzResource -ResourceGroupName OldRG -ResourceName ExampleSite

$plan = Get-AzResource -ResourceGroupName OldRG -ResourceName ExamplePlan
Move-AzResource -DestinationResourceGroupName NewRG -ResourceId $webapp.ResourceId, $plan.ResourceId
Para passar para uma nova subscrição, inclua um valor para o DestinationSubscriptionId parâmetro.
subscrição.
Utilizar a CLI do Azure

Para mover os recursos existentes para outro grupo de recursos ou subscrição, use o comando de movimento de
recursos az. Forneça as iDs de recursos dos recursos para se mover. O exemplo que se segue mostra como
transferir vários recursos para um novo grupo de recursos. No --ids parâmetro, forneça uma lista separada do
espaço dos IDs de recursos para se mover.
webapp=$(az resource show -g OldRG -n ExampleSite --resource-type "Microsoft.Web/sites" --query id --output

tsv)
plan=$(az resource show -g OldRG -n ExamplePlan --resource-type "Microsoft.Web/serverfarms" --query id --
output tsv)
az resource move --destination-group newgroup --ids $webapp $plan
Para passar para uma nova --destination-subscription-id subscrição, forneça o parâmetro.

subscrição.
Utilizar a API REST

Para mover os recursos existentes para outro grupo de recursos ou subscrição, utilize a operação de recursos
Move.
POST https://management.azure.com/subscriptions/{source-subscription-id}/resourcegroups/{source-resource-
group-name}/moveResources?api-version={api-version}
No organismo de pedido, especifica o grupo de recursos-alvo e os recursos para se movimentar.
{
"resources": ["<resource-id-1>", "<resource-id-2>"],
"targetResourceGroup": "/subscriptions/<subscription-id>/resourceGroups/<target-group>"
}
subscrição.
Perguntas mais frequentes

Pergunta: A minha operação de movimento de recursos, que normalmente demora alguns minutos,
está a funcionar há quase uma hora. Passa-se alguma coisa?
Mover um recurso é uma operação complexa que tem diferentes fases. Pode envolver mais do que apenas o
fornecedor de recursos do recurso que está a tentar mover. Devido às dependências entre fornecedores de
recursos, o Gestor de Recursos azure permite que a operação seja concluída. Este período de tempo dá aos
fornecedores de recursos a oportunidade de se recuperarem de questões transitórias. Se o seu pedido de mudança
for dentro do período de 4 horas, a operação continua a tentar concluir e pode ainda ter sucesso. Os grupos de
recursos de origem e destino estão bloqueados durante este tempo para evitar problemas de consistência.
Pergunta: Porque é que o meu grupo de recursos está bloqueado durante 4 horas durante o
movimento de recursos?
A janela de 4 horas é o tempo máximo permitido para a movimentação de recursos. Para evitar modificações nos
recursos que são movidos, tanto os grupos de recursos de origem como os grupos de recursos de destino estão
bloqueados durante a duração do movimento de recursos.
Há duas fases num pedido de mudança. Na primeira fase, o recurso é movido. Na segunda fase, as notificações são
enviadas a outros fornecedores de recursos que dependem da deslocação do recurso. Um grupo de recursos pode
ser bloqueado durante toda a janela de 4 horas quando um fornecedor de recursos falha em qualquer fase.
Durante o tempo permitido, o Gestor de Recursos retenta o passo falhado.
Se um recurso não puder ser movido dentro da janela de 4 horas, o Gestor de Recursos desbloqueia ambos os
grupos de recursos. Os recursos que foram movidos com sucesso estão no grupo de recursos de destino. Os
recursos que não conseguiram mover-se são deixados ao grupo de recursos de origem.
Pergunta: Quais são as implicações dos grupos de recursos de origem e de destino que estão
bloqueados durante o movimento de recursos?
O bloqueio impede-o de eliminar qualquer grupo de recursos, criando um novo recurso em qualquer grupo de
recursos, ou eliminando qualquer um dos recursos envolvidos na mudança.
A imagem que se segue mostra uma mensagem de erro do portal Azure quando um utilizador tenta apagar um
grupo de recursos que faz parte de um movimento em curso.
Pergunta: O que significa o código de erro "MissingMoveDependentResources"?

Ao mover um recurso, os seus recursos dependentes devem existir no grupo de recursos de destino ou subscrição,
ou ser incluídos no pedido de mudança. Obtém o código de erro MissingMoveDependentResources quando um
recurso dependente não cumpre este requisito. A mensagem de erro tem detalhes sobre o recurso dependente que
precisa de ser incluído no pedido de mudança.
Por exemplo, mover uma máquina virtual pode exigir a deslocação de sete tipos de recursos com três fornecedores
de recursos diferentes. Os fornecedores e tipos de recursos são:
Microsoft.Compute
máquinas virtuais
discos
Microsoft.Network
networkInterfaces
endereços públicosIPAddresss
networkSecurityGroups
redes virtuais
Microsoft.Storage
armazenamentoContas
Outro exemplo comum passa pela mudança de uma rede virtual. Pode ter de movimentar vários outros recursos
associados a essa rede virtual. O pedido de mudança poderia exigir a deslocação de endereços IP públicos, tabelas
de rotas, gateways de rede virtuais, grupos de segurança de rede, entre outros.
Pergunta: Por que não posso mover alguns recursos em Azure?
Atualmente, nem todos os recursos em movimento de apoio azure. Para obter uma lista de recursos que apoiem a
mudança, consulte o apoio da operação Move para recursos.
Passos seguintes
Para obter uma lista dos recursos de apoio, consulte o apoio da operação Move para recursos.
Executar tarefas de fundo com WebJobs no Serviço
de Aplicações Azure
Este artigo mostra como implementar webJobs usando o portal Azure para carregar um executável ou script.
Para obter informações sobre como desenvolver e implementar WebJobs utilizando o Visual Studio, consulte o
Deploy WebJobs utilizando o Visual Studio.
Descrição geral
WebJobs é uma funcionalidade do Azure App Service que lhe permite executar um programa ou script no
mesmo caso que uma aplicação web, app API ou aplicação móvel. Não há custos adicionais para usar webJobs.
IMPORTANT
WebJobs ainda não é suportado para o Serviço de Aplicações no Linux.
O Azure WebJobs SDK pode ser usado com WebJobs para simplificar muitas tarefas de programação. Para mais
informações, consulte O Que é o WebJobs SDK.
A Azure Functions fornece outra forma de executar programas e scripts. Para uma comparação entre WebJobs e
Funções, consulte Escolha entre Fluxo, Aplicações Lógicas, Funções e WebJobs.
Tipos webJob
A tabela seguinte descreve as diferenças entre WebJobs contínuos e desencadeados.
C O N T ÍN UO DESEN C A DEA DO
Começa imediatamente quando o WebJob é criado. Para Só começa quando acionado manualmente ou num horário.
evitar que o trabalho termine, o programa ou o guião
normalmente faz o seu trabalho dentro de um ciclo
interminável. Se o trabalho acabar, pode reiniciá-lo.
Funciona em todas as instâncias em que a aplicação web Funciona numa única instância que o Azure seleciona para
funciona. Pode restringir opcionalmente o WebJob a uma equilibrar a carga.
única instância.
Suporta depuração remota. Não suporta depuração remota.
NOTE
Uma aplicação web pode sair após 20 minutos de inatividade. Apenas solicita à aplicação web real redefinir o temporizador.
Visualizar a configuração da aplicação no portal Azure ou https://<app_name>.scm.azurewebsites.net fazer pedidos para
o site de ferramentas avançadas ( ) não redefinir o temporizador. Se a sua aplicação funcionar continuamente ou
programada (gatilho do temporizador), ative sempre on para garantir que os WebJobs funcionam de forma fiável. Esta
funcionalidade está disponível apenas nos níveis de preçosBásico, Standard e Premium.
Tipos de ficheiros suportados para scripts ou programas
São suportados os seguintes tipos de ficheiro:
.cmd, .bat, .exe (usando Windows cmd)
.ps1 (usando powerShell)
.sh (usando Bash)
.php (utilizando PHP)
.py (usando Python)
.js (usando node.js)
.jar (usando Java)
Criar um WebJob contínuo

1. No portal Azure,vá à página do App Ser vice da sua aplicação web do App Service, app API ou aplicação
móvel.
2. Selecione WebJobs .
3. Na página WebJobs, selecione Adicionar .
4. Utilize as definições add WebJob conforme especificado na tabela.

DEF IN IÇ Ã O VA LO R DA A M O ST RA DESC RIÇ Ã O
Nome myContinuousWebJob Um nome único dentro de uma

aplicação de Serviço de Aplicações.
Deve começar com uma letra ou um
número e não pode conter
caracteres especiais que não "-" e "".
Upload de ficheiros ConsoleApp.zip Um ficheiro .zip que contenha o

ficheiro executável ou script, bem
como quaisquer ficheiros de suporte
necessários para executar o
programa ou script. Os tipos de
ficheiros executáveis ou scripts
suportados estão listados na secção
de tipos de ficheiros suportados.
Tipo Contínuo Os tipos WebJob são descritos

anteriormente neste artigo.
Escala Várias instâncias Disponível apenas para WebJobs

Contínuos. Determina se o
programa ou script funciona em
todas as instâncias ou apenas uma
instância. A opção de correr em
várias instâncias não se aplica aos
níveis de preços Gratuitos ou
Partilhados.
5. Clique em OK .
O novo WebJob aparece na página WebJobs.
6. Para parar ou reiniciar um WebJob contínuo, clique no WebJob na lista e clique em Parar ou Iniciar .
Criar um WebJob desencadeado manualmente

móvel.

Nome myTriggeredWebJob Um nome único dentro de uma


Tipo Desencadeado Os tipos WebJob são descritos

Acionadores Manual
5. Clique em OK .
6. Para executar o WebJob, clique no seu nome na lista e clique em Executar .
Criar um WebJob agendado

móvel.

Nome myScheduledWebJob Um nome único dentro de uma


Tipo Desencadeado Os tipos WebJob são descritos

Acionadores Agendado Para que o agendamento funcione

de forma fiável, ative a
funcionalidade Always On. Always
On está disponível apenas nos níveis
de preços Básico, Standard e
Premium.
Expressão CRON 0 0/20 * * * * As expressões cron são descritas na

secção seguinte.
5. Clique em OK .
Expressões NCRONTAB
Pode introduzir uma expressão NCRONTAB no settings.job portal ou incluir um ficheiro na raiz do seu ficheiro
WebJob .zip, como no seguinte exemplo:
{
"schedule": "0 */15 * * * *"
}
Para saber mais, consulte Agendar um WebJob desencadeado.
NOTE
O fuso horário predefinido utilizado para executar expressões CRON é tempo universal coordenado (UTC). Para que a
expressão cronocística funcione com base noutro fuso horário, crie uma definição de aplicação para a sua aplicação de
função chamada WEBSITE_TIME_ZONE. Para saber mais, consulte fusos horários NCRONTAB.
Ver o histórico do trabalho

1. Selecione o WebJob para o qual pretende ver o histórico e, em seguida, selecione o botão Logs.
2. Na página WebJob Details, selecione um momento para ver detalhes para uma execução.
3. Na página WebJob Executar Detalhes, selecione Toggle Output para ver o texto do conteúdo do
registo.
Para ver o texto de saída numa janela separada do navegador, selecione download . Para descarregar o
texto em si, clique no descarregamento e use as opções do seu navegador para guardar o conteúdo do
ficheiro.
4. Selecione o link webJobs breadcrumb na parte superior da página para ir a uma lista de WebJobs.
Próximos passos
O Azure WebJobs SDK pode ser usado com WebJobs para simplificar muitas tarefas de programação. Para mais
informações, consulte O Que é o WebJobs SDK.
Develop and deploy WebJobs using Visual Studio -
Azure App Service (Programar e implementar
WebJobs com o Visual Studio – Serviço de
Aplicações do Azure)
Este artigo explica como usar o Visual Studio para implementar um projeto de Aplicação de Consolas para uma
aplicação web no App Service como um WebJob Azure. Para obter informações sobre como implementar
webJobs utilizando o portal Azure,consulte as tarefas de Fundo de Execução com WebJobs.
Pode publicar vários WebJobs numa única aplicação web. Certifique-se de que cada WebJob numa aplicação web
tem um nome único.
A versão 3.x do Azure WebJobs SDK permite-lhe desenvolver WebJobs que funcionam como aplicações .NET Core
ou .NET Framework, enquanto a versão 2.x suporta apenas o .NET Framework. A forma como implementa um
projeto WebJobs é diferente para projetos .NET Core versus .NET Framework.
WebJobs como .NET Core aplicativos de consola

Ao utilizar a versão 3.x do WebJobs, pode criar e publicar webJobs como aplicações de consola .NET Core. Para
instruções passo a passo para criar e publicar uma aplicação de consola .NET Core para o Azure como webJob,
consulte Get started with the Azure WebJobs SDK para processamento de fundo orientado por eventos.
NOTE
.NET Core WebJobs não pode ser ligado a projetos web. Se precisar de implementar o seu WebJob com uma aplicação web,
deve criar o seu WebJob como uma aplicação de consola .NET Framework.
Implementar no Serviço de Aplicações do Azure

A publicação de um WebJob .NET Core para App Service do Visual Studio utiliza a mesma ferramenta que a
publicação de uma aplicação ASP.NET Core.
1. No Explorador de Soluções , clique com o botão direito do rato no projeto e selecione Publicar .
2. No diálogo Publicar, selecione Microsoft Azure App Ser vice, escolha Criar Novo , e, em seguida,
selecione Publicar .
3. No diálogo Create App Ser vice, utilize as definições de hospedagem conforme especificado na tabela
abaixo da imagem:

Nome da Aplicação Nome globalmente exclusivo Nome que identifica exclusivamente

a sua nova aplicação de funções.
Assinatura Escolher a sua subscrição A subscrição do Azure que deve

utilizar.
Grupo de Recursos myResourceGroup Nome do grupo de recursos no qual

a sua aplicação de funções será
criada. Escolha Novo para criar um
grupo de recursos novo.
Plano de Hospedagem Plano do App Service Um plano do serviço de aplicações

especifica o local, tamanho e
funcionalidades da farm de
servidores Web que aloja a aplicação.
Pode economizar dinheiro ao alojar
várias aplicações, configurando as
aplicações Web para partilhar um
único plano do serviço de aplicações.
Os planos do Serviço de Aplicações
definem a região, o tamanho da
instância, a contagem de escalas e o
SKU (Grátis, Partilhados, Básicos,
Standard ou Premium). Escolha a
Nova para criar um novo plano de
4. Clique em Criar um WebJob e recursos relacionados em Azure com estas definições e implementar o seu
código de projeto.
Tipos webJob
Por padrão, um WebJob publicado a partir de um projeto de consola .NET Core só funciona quando
desencadeado ou a pedido. Também pode atualizar o projeto para executar em horário ou executar
continuamente.
NOTE
Execução programada
Quando publica uma aplicação de consola .NET Core para o Azure, é adicionado ao projeto um novo ficheiro de
definições.job. Utilize este ficheiro para definir um calendário de execução para o seu WebJob. Para mais
informações, consulte Agendar um WebJob acionado.
Execução contínua
Pode utilizar o Visual Studio para alterar o WebJob para funcionar continuamente quando o Always On está
ativado em Azure.
1. Se ainda não o fez, publique o projeto para o Azure.
3. No separador Publicar, escolha Definições .
4. No diálogo definições de perfil, escolha "Contínuo para o Tipo WebJob ", e escolha Guardar .
5. Selecione Publicar para republicar o WebJob com as definições atualizadas.
WebJobs como .NET Aplicativos de consola-quadro

Quando o Visual Studio implementa um projeto de aplicação de consolas de estrutura .NET ativado pela WebJobs,
copia ficheiros de tempo de execução para a pasta apropriada na aplicação web (App_Data/jobs/continuous para
WebJobs contínuos e App_Data/jobs/triggerpara WebJobs programado ou a pedido).
Um projeto ativado pela WebJobs tem os seguintes itens adicionados:
O pacote Microsoft.web.webjobs.Publish nuget.
Um ficheiro webjob-publish-settings.json que contém definições de implantação e programador.
Pode adicionar estes itens a um projeto de aplicação de consola existente ou utilizar um modelo para criar um
novo projeto de aplicação de consola santiva ativado pelo WebJobs.
Pode implementar um projeto como WebJob por si só, ou ligá-lo a um projeto web para que ele implemente
automaticamente sempre que implementa o projeto web. Para ligar projetos, o Visual Studio inclui o nome do
projeto ativado pela WebJobs num ficheiro webjobs-list.json no projeto web.
Pré -requisitos
Se estiver a utilizar o Visual Studio 2015, instale o Azure SDK para .NET (Visual Studio 2015).
Se estiver a utilizar o Visual Studio 2017, instale a carga de trabalho de desenvolvimento do Azure.
Ativar a implementação webJobs para um projeto de aplicação de consola existente
Tem duas opções:
Ativar a implementação automática com um projeto web.
Configure um projeto de aplicação de consola existente para que ele implemente automaticamente como
um WebJob quando implementa um projeto web. Utilize esta opção quando pretender executar o seu
WebJob na mesma aplicação web na qual executa a aplicação web relacionada.
Ativar a implementação sem um projeto web.
Configure um projeto de aplicação de consola existente para implementar como um WebJob por si só, sem
qualquer ligação a um projeto web. Utilize esta opção quando pretender executar um WebJob numa
aplicação web por si só, sem que nenhuma aplicação web esteja a funcionar na aplicação web. Talvez queira
fazê-lo para poder escalar os seus recursos WebJob independentemente dos seus recursos de aplicação
web.
Ativar a implementação automática de WebJobs com um projeto web
1. Clique no projeto web no Solution Explorer e, em seguida, clique em Adicionar > Projeto Existente
como Azure WebJob .
Aparece a caixa de diálogo Add Azure WebJob.

2. Na lista de lançamentos do nome do Projeto, selecione o projeto de Aplicação de Consola para adicionar
como WebJob.
3. Complete o diálogo Add Azure WebJob e, em seguida, clique em OK .
Ativar a implementação webJobs sem um projeto web
1. Clique no projeto de aplicação da consola no Solution Explorer e clique em Publicar como Azure
WebJob....
Aparece a caixa de diálogo Add Azure WebJob, com o projeto selecionado na caixa de nome sinuosa do
Projeto.
2. Complete a caixa de diálogo Add Azure WebJob e, em seguida, clique em OK .
O assistente da Web publicar aparece. Se não quiser publicar imediatamente, feche o assistente. As
definições que introduziu são guardadas para quando pretende implementar o projeto.
Criar um novo projeto ativado pela WebJobs
Para criar um novo projeto ativado pelo WebJobs, pode utilizar o modelo do projeto de aplicação de consolae e
permitir a implementação do WebJobs, tal como explicado na secção anterior. Como alternativa, pode utilizar o
modelo de novo projeto WebJobs:
Use o modelo de novo projeto WebJobs para um WebJob independente
Crie um projeto e configure-o para implementar por si mesmo como um WebJob, sem qualquer ligação a
um projeto web. Utilize esta opção quando pretender executar um WebJob numa aplicação web por si só,
sem que nenhuma aplicação web esteja a funcionar na aplicação web. Talvez queira fazê-lo para poder
escalar os seus recursos WebJob independentemente dos seus recursos de aplicação web.
Use o modelo de novo projeto WebJobs para um WebJob ligado a um projeto web
Crie um projeto que esteja configurado para implementar automaticamente como Um WebJob quando um
projeto web na mesma solução é implementado. Utilize esta opção quando pretender executar o seu
WebJob na mesma aplicação web na qual executa a aplicação web relacionada.
NOTE
O modelo de novo projeto WebJobs instala automaticamente pacotes NuGet e inclui código em Program.cs para o
WebJobs SDK. Se não quiser utilizar o WebJobs SDK, remova host.RunAndBlock ou altere a declaração em Program.cs.
Use o modelo de novo projeto WebJobs para um WebJob independente

1. Clique em File > New Project , e depois na caixa de diálogo New Project clique em Cloud > Azure
WebJob (.NET Framework) .
2. Siga as instruções anteriormente mostradas para tornar o projeto de Aplicação de Consola um projeto
WebJobs independente.
Use o modelo de novo projeto WebJobs para um WebJob ligado a um projeto web
1. Clique no projeto web no Solution Explorer e, em seguida, clique em Adicionar > Novo Projeto
WebJob Azure .
Aparece a caixa de diálogo Add Azure WebJob.
2. Complete a caixa de diálogo Add Azure WebJob e, em seguida, clique em OK .
O diálogo WebJob Add Azure
O diálogo Add Azure WebJob permite introduzir o nome WebJob e executar a definição de modo para o seu
WebJob.
Os campos deste diálogo correspondem aos campos do diálogo Add WebJob do portal Azure. Para mais
informações, consulte executar tarefas de Fundo com WebJobs.
NOTE
Para obter informações sobre a implantação da linha de comando, consulte a linha de comando ativação ou a entrega
contínua de WebJobs Azure.
Se implementar um WebJob e decidir que pretende alterar o tipo de WebJob e reimplementar, terá de eliminar o ficheiro
webjobs-publish-settings.json. Isto fará com que o Visual Studio mostre as opções de publicação novamente, para que
possa alterar o tipo de WebJob.
Se implementar um WebJob e, mais tarde, alterar o modo de execução de contínuo para não-contínuo ou vice-versa, o
Visual Studio cria um novo WebJob em Azure quando reimplanta. Se alterar outras definições de agendamento, mas
deixar o modo de execução o mesmo ou alternar entre o Scheduled e o On Demand, o Visual Studio atualiza o trabalho
existente em vez de criar um novo.
webjob-publish-settings.json
Quando configura uma aplicação de consola para implementação webJobs, o Visual Studio instala o pacote
Microsoft.Web.WebJobs.Publish NuGet e armazena informações de agendamento num ficheiro webjob-publish-
settings.json na pasta do projeto Propriedades do projeto WebJobs. Aqui está um exemplo desse ficheiro:
{
"$schema": "http://schemastore.org/schemas/json/webjob-publish-settings.json",
"webJobName": "WebJob1",
"startTime": "null",
"endTime": "null",
"jobRecurrenceFrequency": "null",
"interval": null,
"runMode": "Continuous"
}
Pode editar este ficheiro diretamente, e o Visual Studio fornece o IntelliSense. O esquema do ficheiro é
https://schemastore.org armazenado e pode ser visto lá.
webjobs-list.json
Quando liga um projeto ativado pela WebJobs a um projeto web, o Visual Studio armazena o nome do projeto
WebJobs num ficheiro webjobs-list.json na pasta Propriedades do projeto web. A lista pode conter vários projetos
WebJobs, como mostra o seguinte exemplo:
{
"$schema": "http://schemastore.org/schemas/json/webjobs-list.json",
"WebJobs": [
{
"filePath": "../ConsoleApplication1/ConsoleApplication1.csproj"
},
{
"filePath": "../WebJob1/WebJob1.csproj"
}
]
}
Pode editar este ficheiro diretamente, e o Visual Studio fornece o IntelliSense. O esquema do ficheiro é
https://schemastore.org armazenado e pode ser visto lá.
Implementar um projeto WebJobs
Um projeto WebJobs que ligou a um projeto web implementa automaticamente com o projeto web. Para obter
informações sobre a implementação do projeto web, consulte como orientar > a aplicação Deploy na
navegação à esquerda.
Para implementar um projeto WebJobs por si só, clique no projeto no Solution Explorer e clique em Publicar
como Azure WebJob....
Para um WebJob independente, aparece o mesmo assistente Web publish que é usado para projetos web, mas
com menos configurações disponíveis para alterar.
Agendar um WebJob acionado

WebJobs usa um ficheiro de definições.job para determinar quando um WebJob é executado. Utilize este ficheiro
para definir um calendário de execução para o seu WebJob. O seguinte exemplo decorre de hora em hora das
9:00 às 17:00:
{
"schedule": "0 0 9-17 * * *"
}
Este ficheiro deve estar localizado na raiz da pasta WebJobs, juntamente

wwwroot\app_data\jobs\triggered\{job name} com wwwroot\app_data\jobs\continuous\{job name} o script do
webJob, como ou . Quando implementar um WebJob do Visual settings.job Studio, marque as propriedades
dos seus ficheiros como Copy se for mais recente .
Quando cria um WebJob a partir do portal Azure,o ficheiro definições.job é criado para si.
NOTE
Expressões cron
WebJobs usa as mesmas expressões cron para agendamento que o gatilho do temporizador nas Funções Azure.
Para saber mais sobre o suporte do CRON, consulte o artigo de referência do gatilho do temporizador.
NOTE
O fuso horário predefinido utilizado para executar expressões CRON é tempo universal coordenado (UTC). Para que a
expressão cronocística funcione com base noutro fuso horário, crie uma definição de aplicação para a sua aplicação de
função chamada WEBSITE_TIME_ZONE. Para saber mais, consulte fusos horários NCRONTAB.
definições.referência de trabalho
As seguintes definições são suportadas pelo WebJobs:
DEF IN IÇ Ã O T IP O DESC RIÇ Ã O
is_in_place Todos Permite que o trabalho seja executado

no lugar sem ser copiado primeiro para
uma pasta temporária. Para saber mais,
consulte o diretório de trabalho
webJobs.
is_singleton Contínuo Só execute os WebJobs numa única

instância quando for dimensionado.
Para saber mais, consulte Definir um
trabalho contínuo como singleton.
schedule Desencadeado Execute o WebJob num horário

baseado em CRON. Para saber mais,
consulte o temporizador de referência.
stopping_wait_time Todos Permite o controlo do comportamento

de encerramento. Para saber mais,
consulte a paragem graciosa.
Passos seguintes
Saiba mais sobre o WebJobs SDK
Get started with the Azure WebJobs SDK for event-
driven background processing (Introdução ao SDK
de WebJobs do Azure para processamento em
segundo plano condicionado por eventos)
Este artigo mostra como usar o Visual Studio 2019 para criar um projeto Azure WebJobs SDK, executá-lo
localmente e, em seguida, implementá-lo para o Azure App Service. A versão 3.x do WebJobs SDK suporta
aplicações de consola .NET Core e .NET Framework. Para saber mais sobre o trabalho com o WebJobs SDK,
consulte como utilizar o Azure WebJobs SDK para processamento de fundo orientadopara eventos .
Este artigo mostra-lhe como implementar webJobs como uma aplicação de consola .NET Core. Para implementar
webJobs como uma aplicação de consola .NET Framework, consulte webJobs como aplicações de consola .NET
Framework. Se estiver interessado na versão 2.x do WebJobs SDK, que apenas suporta o .NET Framework,
consulte Desenvolver e implementar WebJobs utilizando o Visual Studio - Azure App Service.
Pré-requisitos
Instale o Visual Studio 2019 com a carga de trabalho de desenvolvimento do Azure. Se já tem o Visual
Studio mas não tem essa carga de trabalho, adicione a carga de trabalho selecionando Ferramentas >
Obter Ferramentas e Funcionalidades .
Deve ter uma conta Azure para publicar o seu projeto WebJobs SDK para o Azure.
Criar um projeto
1. No Estúdio Visual, selecione Criar um Novo Projeto.
2. Selecione App consola (.NET Core) .
3. Nomeie o projeto WebJobsSDKSamplee, em seguida, selecione Criar .
Pacotes WebJobs NuGet
1. Instale a mais recente versão estável 3.x do Microsoft.Azure.WebJobs.Extensions pacote NuGet,que inclui
Microsoft.Azure.WebJobs .
Aqui está o comando de consola do gestor de pacotes:
Install-Package Microsoft.Azure.WebJobs.Extensions -version <3_X_VERSION>
Neste comando, <3_X_VERSION> substitua-o por uma versão suportada do pacote.
Criar o Anfitrião
O hospedeiro é o recipiente de tempo de funcionamento para funções que ouvem os gatilhos e as funções de
chamadas. Os seguintes passos criam um hospedeiro que implementa IHost , que é o Anfitrião Genérico em
ASP.NET Core.
1. Em Program.cs, adicione estas using declarações:
using System.Threading.Tasks;
using Microsoft.Extensions.Hosting;
2. Substitua o método Main pelo código abaixo:

static async Task Main()
{
var builder = new HostBuilder();
builder.ConfigureWebJobs(b =>
{
b.AddAzureStorageCoreServices();
});
var host = builder.Build();
using (host)
{
await host.RunAsync();
}
}
Em ASP.NET Core, as configurações do hospedeiro são definidas através de métodos de chamada na HostBuilder
instância. Para mais informações, consulte .NET Generic Host. O método de ConfigureWebJobs extensão inicializa o
anfitrião WebJobs. Em ConfigureWebJobs , inicializa extensões específicas do WebJobs e define propriedades
dessas extensões.
Ativar o registo de consolas

Nesta secção, configura o registo de consolas que utiliza a estrutura de registo do Núcleo de ASP.NET.
1. Instale a versão mais recente estável do Microsoft.Extensions.Logging.Console pacote NuGet,que inclui
Microsoft.Extensions.Logging .
Install-Package Microsoft.Extensions.Logging.Console -version <3_X_VERSION>
Neste comando, <3_X_VERSION> substitua-o por uma versão 3.x suportada da embalagem.
2. Em Program.cs, adicione um using comunicado:
using Microsoft.Extensions.Logging;
3. Ligue para o ConfigureLogging HostBuilder método. O AddConsole método adiciona o registo da consola
à configuração.
builder.ConfigureLogging((context, b) =>
{
b.AddConsole();
});
O Main método agora é assim:

{
{
});
{
b.AddConsole();
});
using (host)
{
}
}
Esta atualização faz o seguinte:

Desativa a exploração do painelde instrumentos. O dashboard é uma ferramenta de monitorização
antiga, e a exploração do dashboard não é recomendada para cenários de produção de alta produção.
Adiciona o fornecedor de consolas com filtragempadrão .
Agora, pode adicionar uma função que é desencadeada por mensagens que chegam numa fila de
Armazenamento Azure.
Instalar a extensão de enlace do Armazenamento

A partir da versão 3.x, deve instalar explicitamente a extensão de encadernação de Armazenamento exigida pelo
WebJobs SDK. Em versões anteriores, as encadernações de Armazenamento foram incluídas no SDK.
1. Instale a versão mais recente estável do microsoft.Azure.WebJobs.Extensions.Storage NuGet, versão 3.x.
Install-Package Microsoft.Azure.WebJobs.Extensions.Storage -Version <3_X_VERSION>

2. No método de ConfigureWebJobs extensão, ligue para o AddAzureStorage método da instância para
HostBuilder inicializar a extensão de armazenamento. Neste ponto, o ConfigureWebJobs método parece
ser o seguinte exemplo:
{
b.AddAzureStorage();
});
Criar uma função

1. Clique no projeto, selecione Adicionar > Novo Item... escolha Classe, nomeie o novo ficheiro de classe
C# Functions.cs, e selecione Adicionar .
2. Em Functions.cs, substitua o modelo gerado pelo seguinte código:
using Microsoft.Azure.WebJobs;
using Microsoft.Extensions.Logging;
namespace WebJobsSDKSample
{
public class Functions
{
public static void ProcessQueueMessage([QueueTrigger("queue")] string message, ILogger logger)
{
logger.LogInformation(message);
}
}
}
O atributo diz o tempo de QueueTrigger funcionamento para chamar esta função quando uma nova
mensagem é escrita numa fila de Armazenamento Azure chamada queue . O conteúdo da mensagem de
fila é fornecido ao código do método no message parâmetro. O corpo do método é onde processa os
dados do gatilho. Neste exemplo, o código apenas regista a mensagem.
O message parâmetro não tem de ser uma corda. Também pode ligar-se a um objeto JSON, uma matriz de
byte ou um objeto CloudQueueMessage. Consulte a utilização do gatilhoda fila . Cada tipo de
encadernação (como filas, bolhas ou mesas) tem um conjunto diferente de tipos de parâmetros a que se
pode ligar.
Criar uma conta de armazenamento

O emulador de armazenamento Azure que funciona localmente não tem todas as funcionalidades de que o
WebJobs SDK necessita. Assim, nesta secção, cria-se uma conta de armazenamento no Azure e configura o
projeto para o utilizar. Se já tem uma conta de armazenamento, salte para o passo 6.
1. Open Ser ver Explorer em estúdio visual e inscreva-se no Azure. Clique no nó Azure e, em seguida,
selecione Connect para a Subscrição Microsoft Azure .
2. Sob o nó Azure no Ser ver Explorer, clique no armazenamento do clique direito, e depois selecione
create storage .
3. Na caixa de diálogo 'Conta de Armazenamento Criar', introduza um nome único para a conta de
armazenamento.
4. Escolha a mesma Região em que criou a sua app App Service, ou uma região próxima de si.
6. Sob o nó de Armazenamento no Ser ver Explorer, selecione a nova conta de Armazenamento. Na janela
Propriedades, selecione a elipse (...) à direita do campo de valor de fio de ligação.
7. Copie a cadeia de ligação e guarde este valor em algum lugar onde possa copiá-la de novo prontamente.
Configure armazenamento para executar localmente

O WebJobs SDK procura a cadeia de ligação de armazenamento nas Definições de Aplicação em Azure. Quando
corre localmente, procura este valor no ficheiro de configuração local ou em variáveis ambientais.
1. Clique no projeto, selecione Adicionar > Novo Item...- escolha o ficheiro de configuração JavaScript
JSON, nomeie as novas aplicações de ficheiros.json e selecione Adicionar .
2. No novo ficheiro, adicione um AzureWebJobsStorage campo, como no seguinte exemplo:
{
"AzureWebJobsStorage": "{storage connection string}"
}
3. Substitua a cadeia de ligação de {armazenamento} com a cadeia de ligação que copiou anteriormente.
4. Selecione o ficheiro appsettings.json no Solution Explorer e na janela Proper ties, coloque copy to
Output Director y to Copy se for mais recente .
Mais tarde, irá adicionar a mesma definição de aplicação de cadeiade ligação na sua aplicação no Serviço de
Aplicações Azure.
Teste local
Nesta secção, você constrói e executa o projeto localmente e despoleta a função criando uma mensagem de fila.
1. Prima Ctrl+F5 para executar o projeto.
A consola mostra que o tempo de execução encontrou a sua função e está à espera que as mensagens de
fila a desencadeiem. A seguinte saída é gerada pelo anfitrião v3.x:
info: Microsoft.Azure.WebJobs.Hosting.JobHostService[0]
Starting JobHost
info: Host.Startup[0]
Found the following functions:
WebJobsSDKSample.Functions.ProcessQueueMessage
info: Host.Startup[0]
Job host started
Application started. Press Ctrl+C to shut down.
Hosting environment: Development
Content root path: C:\WebJobsSDKSample\WebJobsSDKSample\bin\Debug\netcoreapp2.1\
2. Feche a janela da consola.

3. No Ser ver Explorer no Estúdio Visual, expanda o nó para a sua nova conta de armazenamento e, em
seguida, clique nas filas de clique si .
4. Selecione Criar fila .
5. Introduza a fila como o nome da fila e, em seguida, selecione OK .
6. Clique no nó direito para a nova fila e, em seguida, selecione Ver Fila .

7. Selecione o ícone adicionar mensagem.
8. No diálogo Add Message, introduza Hello World! como texto de mensagem , e depois selecione OK . Há
agora uma mensagem na fila.
9. Execute novamente o projeto.

Como usou o QueueTrigger atributo na ProcessQueueMessage função, o tempo de funcionamento do
WeJobs SDK ouve mensagens de fila quando começa. Encontra uma nova mensagem de fila na fila
chamada fila e chama a função.
Devido ao recuo exponencial das sondagens,pode levar até 2 minutos para o tempo de funcionamento
encontrar a mensagem e invocar a função. Este tempo de espera pode ser reduzido funcionando no modo
de desenvolvimento.
A saída da consola é assim:
info: Function.ProcessQueueMessage[0]
Executing 'Functions.ProcessQueueMessage' (Reason='New queue message detected on 'queue'.',
Id=2c319369-d381-43f3-aedf-ff538a4209b8)
Trigger Details: MessageId: b00a86dc-298d-4cd2-811f-98ec39545539, DequeueCount: 1,
InsertionTime: 1/18/2019 3:28:51 AM +00:00
info: Function.ProcessQueueMessage.User[0]
Hello World!
Executed 'Functions.ProcessQueueMessage' (Succeeded, Id=2c319369-d381-43f3-aedf-ff538a4209b8)

11. Volte para a janela da fila e refresque-a. A mensagem desapareceu, uma vez que foi processada pela sua
função a funcionar localmente.
Adicionar registo de insights de aplicação

Quando o projeto funciona em Azure, não é possível monitorizar a execução da função visualizando a saída da
consola. A solução de monitorização que recomendamos é A Aplicação Insights. Para mais informações, consulte
as Funções Monitor Azure.
Nesta secção, você faz as seguintes tarefas para configurar a registo de Insights de Aplicação antes de se deslocar
para o Azure:
Certifique-se de que tem uma aplicação de Serviço de Aplicações e uma instância de Insights de Aplicação
para trabalhar.
Configure a aplicação app Service para utilizar a instância Deinsights de Aplicação e a conta de
armazenamento que criou anteriormente.
Configurar o projeto de login para Application Insights.
Criar app de serviço de aplicações e instância de Insights de Aplicação
1. Se ainda não tem uma aplicação do App Service que pode usar, crie uma. Ao criar a sua aplicação, também
pode criar um recurso de Insights de Aplicação conectado. Quando o fizer, o
APPINSIGHTS_INSTRUMENTATIONKEY está definido para si na sua aplicação.
2. Se ainda não tiver um recurso Application Insights que possa utilizar, crie um. Definir o tipo de aplicação
para general, e saltar as secções que seguem Copiar a chave de instrumentação .
3. Se já tiver um recurso Application Insights que deseja utilizar, copie a chave de instrumentação.
1. No Ser ver Explorer em Visual Studio, expanda o nó do Serviço de Aplicações sob o Azure .
2. Expanda o grupo de recursos em que a sua aplicação app Service está e, em seguida, clique na sua
aplicação App Service.
3. Selecione Definições de visualização .
4. Na caixa de cordas de ligação, adicione a seguinte entrada.
NAME C O N EXÃ O ST RIN G T IP O DE B A SE DE DA DO S
AzureWebJobsStorage {a cadeia de ligação de Personalizar

armazenamento que copiou
anteriormente}
5. Se a caixa de Definições de Aplicação não tiver uma chave de instrumentação De Insights de Aplicação,
adicione a que copiou anteriormente. (A chave de instrumentação pode já estar lá, dependendo da forma
como criou a app App Service.)
NAME VA LO R
APPINSIGHTS_INSTRUMENTATIONKEY {chave de instrumentação}
6. Substitua a tecla {instrumentação} com a chave de instrumentação do recurso Application Insights que está
a utilizar.
8. Adicione a ligação De Insights de Aplicação ao projeto para que possa executá-lo localmente. No ficheiro
appsettings.json, adicione um APPINSIGHTS_INSTRUMENTATIONKEY campo, como no seguinte exemplo:
{
"AzureWebJobsStorage": "{storage connection string}",
"APPINSIGHTS_INSTRUMENTATIONKEY": "{instrumentation key}"
}
Substitua a tecla {instrumentação} com a chave de instrumentação do recurso Application Insights que está
a utilizar.
9. Guarde as alterações.
Adicionar fornecedor de registo de Insights de Aplicação
Para tirar partido da registo de Informação sobre a Aplicação Insights, atualize o seu código de registo para fazer
o seguinte:
Adicione um fornecedor de registo de Insights de Aplicação com filtragempor defeito . Ao executar localmente,
todas as Informações e registos de alto nível são escritos tanto para a consola como para os Insights de
Aplicação.
Coloque o objeto LoggerFactory num bloco para garantir que a saída de using registo é lavada quando o
hospedeiro sair.
1. Instale a mais recente versão estável 3.x do Microsoft.Azure.WebJobs.Logging.ApplicationInsights pacote
NuGet.
Install-Package Microsoft.Azure.WebJobs.Logging.ApplicationInsights -Version <3_X_VERSION>

2. Abra Program.cs e substitua o código no Main método pelo seguinte código:
{
builder.UseEnvironment(EnvironmentName.Development);
{
});
{
b.AddConsole();
// If the key exists in settings, use it to enable Application Insights.

string instrumentationKey = context.Configuration["APPINSIGHTS_INSTRUMENTATIONKEY"];
if (!string.IsNullOrEmpty(instrumentationKey))
{
b.AddApplicationInsightsWebJobs(o => o.InstrumentationKey = instrumentationKey);
}
});
using (host)
{
}
}
Isto adiciona o fornecedor de Insights de Aplicação à exploração madeireira, utilizando a chave que
adicionou anteriormente às definições da sua aplicação.
Registo de insights de aplicação de teste

Nesta secção, corre novamente localmente para verificar se os dados de registo vão agora para a Aplicação
Insights, bem como para a consola.
1. Use ser ver Explorer no Estúdio Visual para criar uma mensagem de fila como fez anteriormente, exceto
insira Hello App Insights! como o texto da mensagem.
2. Executar o projeto.
O WebJobs SDK processa a mensagem da fila e vê os registos na janela da consola.
4. Vá ao portal Azure para ver o seu recurso Application Insights. Procure e selecione Insights de Aplicação .
5. Escolha a sua instância de Insights de Aplicação.
6. Selecione Procurar .
7. Se não vir as Hello App Insights! mensagem, selecione Refresh periodicamente durante vários minutos.
(Os registos não aparecem imediatamente, porque demora algum tempo para o cliente da Application
Insights descarregar os registos que processa.)
Durante a implementação, cria uma instância de serviço de aplicações para executar as suas funções. Quando
publica uma aplicação de consola .NET Core para o App Service em Azure, é executada automaticamente como
Um WebJob. Para saber mais sobre a publicação, consulte Desenvolver e implementar WebJobs usando o Visual
Studio.
2. No diálogo Publicar, selecione Microsoft Azure App Ser vice, escolha Criar Novo , e, em seguida,
selecione Publicar .
3. No diálogo Create App Ser vice, utilize as definições de hospedagem conforme especificado na tabela
abaixo da imagem:
Nome da Aplicação Nome globalmente exclusivo Nome que identifica exclusivamente

a sua nova aplicação de funções.
Assinatura Escolher a sua subscrição A subscrição do Azure que deve

utilizar.
Grupo de Recursos myResourceGroup Nome do grupo de recursos no qual

a sua aplicação de funções será
criada. Escolha Novo para criar um
grupo de recursos novo.
Plano de Hospedagem Plano do App Service Um plano do serviço de aplicações

especifica o local, tamanho e
funcionalidades da farm de
servidores Web que aloja a aplicação.
Pode economizar dinheiro ao alojar
várias aplicações, configurando as
aplicações Web para partilhar um
único plano do serviço de aplicações.
Os planos do Serviço de Aplicações
definem a região, o tamanho da
instância, a contagem de escalas e o
SKU (Grátis, Partilhados, Básicos,
Standard ou Premium). Escolha a
Nova para criar um novo plano de
4. Clique em Criar um WebJob e recursos relacionados em Azure com estas definições e implementar o seu
código de projeto.
Desencadear a função em Azure

1. Certifique-se de que não está a funcionar localmente (feche a janela da consola se ainda estiver aberta).
Caso contrário, a instância local pode ser a primeira a processar quaisquer mensagens de fila que crie.
2. Na página de fila no Estúdio Visual, adicione uma mensagem à fila como antes.
3. Refresque a página de Fila e a nova mensagem desaparece porque foi processada pela função em
funcionamento em Azure.
TIP
Quando estiver a testar em Azure, utilize o modo de desenvolvimento para garantir que uma função de gatilho de
fila seja invocada imediatamente e evite atrasos devido ao recuo exponencial das sondagensem fila .
Ver registos em Insights de Aplicação

1. Abra o portal Azuree vá ao seu recurso Application Insights.
2. Selecione Procurar .
3. Se não virem o Hello Azure! mensagem, selecione Refresh periodicamente durante vários minutos.
Você vê os registos da função em execução num WebJob, incluindo o Hello Azure! texto que inseriu na
secção anterior.
Adicione uma encadernação de entrada
As encadernações de entrada simplificam o código que lê os dados. Para este exemplo, a mensagem de fila será
um nome blob e você usará o nome blob para encontrar e ler uma bolha no Armazenamento Azure.
1. Em Functions.cs, substitua o ProcessQueueMessage método pelo seguinte código:
public static void ProcessQueueMessage(

[QueueTrigger("queue")] string message,
[Blob("container/{queueTrigger}", FileAccess.Read)] Stream myBlob,
ILogger logger)
{
logger.LogInformation($"Blob name:{message} \n Size: {myBlob.Length} bytes");
}
Neste código, queueTrigger encontra-se uma expressão vinculativa,o que significa que se resolve a um
valor diferente no prazo de funcionamento. No tempo de funcionação, tem o conteúdo da mensagem de
fila.
2. Adicione using um:
using System.IO;
3. Crie um recipiente de bolhas na sua conta de armazenamento.

a. No Ser ver Explorer no Estúdio Visual, expanda o nó para a sua conta de armazenamento, clique no
clique direito blobs, e depois selecione Create Blob Container .
b. No diálogo do recipiente Create Blob, introduza o recipiente como nome do recipiente e, em seguida,
clique OK .
4. Faça o upload do ficheiro Program.cs para o recipiente de bolhas. (Este ficheiro é utilizado aqui como
exemplo; pode carregar qualquer ficheiro de texto e criar uma mensagem de fila com o nome do ficheiro.)
a. No Ser ver Explorer, clique duas vezes no nó para o recipiente que criou.
b. Na janela do recipiente, selecione o botão upload.
c. Encontre e selecione Program.cs, e depois selecione OK .

5. Crie uma mensagem de fila na fila que criou anteriormente, com Program.cs como texto da mensagem.
6. Executar o projeto localmente.
A mensagem de fila aciona a função, que depois lê a bolha e regista o seu comprimento. A saída da consola
é assim:
Found the following functions:

ConsoleApp1.Functions.ProcessQueueMessage
Job host started
Executing 'Functions.ProcessQueueMessage' (Reason='New queue message detected on 'queue'.',
Id=5a2ac479-de13-4f41-aae9-1361f291ff88)
Blob name:Program.cs
Size: 532 bytes
Executed 'Functions.ProcessQueueMessage' (Succeeded, Id=5a2ac479-de13-4f41-aae9-1361f291ff88)
Adicionar um enlace de saída

As encadernações de saída simplificam o código que escreve os dados. Este exemplo modifica o anterior
escrevendo uma cópia da bolha em vez de registar o seu tamanho. As encadernações de armazenamento blob
estão incluídas no pacote de extensão de armazenamento Azure que instalámos anteriormente.
1. Substitua o método ProcessQueueMessage pelo código abaixo:
public static void ProcessQueueMessage(

[QueueTrigger("queue")] string message,
[Blob("container/{queueTrigger}", FileAccess.Read)] Stream myBlob,
[Blob("container/copy-{queueTrigger}", FileAccess.Write)] Stream outputBlob,
ILogger logger)
{
logger.LogInformation($"Blob name:{message} \n Size: {myBlob.Length} bytes");
myBlob.CopyTo(outputBlob);
}
2. Crie outra mensagem de fila com Program.cs como texto da mensagem.

3. Executar o projeto localmente.
A mensagem de fila aciona a função, que depois lê a bolha, regista o seu comprimento e cria uma nova
bolha. A saída da consola é a mesma, mas quando se vai à janela do recipiente blob e seleciona Refresh,
vê-se uma nova bolha chamada copy-Program.cs.
Republique as atualizações para o Azure
2. No diálogo Publicar, certifique-se de que o perfil atual é selecionado e, em seguida, escolha Publicar . Os
resultados da publicação são detalhados na janela Output.
3. Verifique a função em Azure, enviando novamente um ficheiro para o recipiente blob e adicionando uma
mensagem à fila que é o nome do ficheiro carregado. Vê a mensagem ser removida da fila e uma cópia do
ficheiro criado no recipiente de bolhas.
Passos seguintes
Este artigo mostrou-lhe como criar, executar e implementar um projeto WebJobs SDK 3.x.
Saiba mais sobre o WebJobs SDK
How to use the Azure WebJobs SDK for event-
driven background processing (Como utilizar o SDK
de WebJobs do Azure para processamento em
segundo plano condicionado por eventos)
Este artigo fornece orientações sobre como trabalhar com o Azure WebJobs SDK. Para começar com webJobs
imediatamente, consulte Começar com o Azure WebJobs SDK para processamento de fundo orientado por
eventos.
Versões WebJobs SDK

Estas são as principais diferenças entre a versão 3. x e versão 2. x do WebJobs SDK:
Versão 3. x adiciona suporte para .NET Core.
Na versão 3. x, você precisa instalar explicitamente a extensão de ligação de armazenamento exigida pelo
WebJobs SDK. Na versão 2. x, as ligações de armazenamento foram incluídas no SDK.
Ferramentas de Estúdio Visual para .NET Core (3.* x*) os projetos diferem da ferramenta para .NET Framework
(2.* x*) projetos. Para saber mais, consulte Desenvolver e implementar WebJobs utilizando o Visual Studio -
Azure App Service.
Quando possível, são fornecidos exemplos para ambas as versões 3. x e versão 2. x.
NOTE
As Funções Azure são construídas no WebJobs SDK, e este artigo fornece links para documentação de Funções Azure para
alguns tópicos. Note estas diferenças entre funções e o WebJobs SDK:
Azure Funções versão 2. x corresponde à versão 3 da WebJobs SDK. x, e Funções Azure 1. x corresponde ao WebJobs
SDK 2. x. Os repositórios de código fonte utilizam a numeragem SDK do WebJobs.
O código de amostra para bibliotecas de classe Azure Functions C# é como o código WebJobs SDK, exceto que não
precisa de um FunctionName atributo num projeto WebJobs SDK.
Alguns tipos de ligação são suportados apenas em Funções, como HTTP (Webhooks) e Event Grid (que é baseado em
HTTP).
Para obter mais informações, consulte as funções WebJobs SDK e Azure.
WebJobs anfitrião
O hospedeiro é um recipiente de tempo de funcionamento para funções. Ouve funções de gatilhos e chamadas.
Na versão 3. x, o hospedeiro é uma implementação de IHost . Na versão 2. x, usa-se o JobHost objeto. Cria uma
instância de anfitrião no seu código e escreve código para personalizar o seu comportamento.
Esta é uma diferença fundamental entre usar o WebJobs SDK diretamente e usá-lo indiretamente através de
Funções Azure. Em Funções Azure, o serviço controla o anfitrião e não é possível personalizar o anfitrião
escrevendo código. As Funções Azure permitem personalizar o comportamento do anfitrião através de definições
no ficheiro host.json. Essas definições são cordas, não código, e isto limita os tipos de personalizações que você
pode fazer.
Cadeias de conexão do anfitrião
O WebJobs SDK procura as cordas de conexão Azure Storage e Azure Service Bus no ficheiro local.settings.json
quando funciona localmente, ou no ambiente do WebJob quando corre em Azure. Por predefinição, é necessária
uma definição de cadeia de ligação de armazenamento AzureWebJobsStorage nomeada.
Versão 2. x do SDK permite-lhe usar os seus próprios nomes para estas cordas de ligação ou armazená-las em
outro lugar. Pode definir nomes em código usando o JobHostConfiguration , como mostrado aqui:
static void Main(string[] args)

{
var _storageConn = ConfigurationManager
.ConnectionStrings["MyStorageConnection"].ConnectionString;
//// Dashboard logging is deprecated; use Application Insights.

//var _dashboardConn = ConfigurationManager
// .ConnectionStrings["MyDashboardConnection"].ConnectionString;
JobHostConfiguration config = new JobHostConfiguration();

config.StorageConnectionString = _storageConn;
//config.DashboardConnectionString = _dashboardConn;
JobHost host = new JobHost(config);
host.RunAndBlock();
}
Porque a versão 3. x utiliza as APIs de configuração de núcleo padrão.NET, não existe API para alterar nomes de
cadeias de ligação.
Configurações de desenvolvimento do anfitrião
Você pode executar o anfitrião em modo de desenvolvimento para tornar o desenvolvimento local mais eficiente.
Aqui estão algumas das definições que são alteradas quando funciona no modo de desenvolvimento:
P RO P RIEDA DE DEF IN IÇ Ã O DE DESEN VO LVIM EN TO
Tracing.ConsoleLevel TraceLevel.Verbose para maximizar a saída de log.
Queues.MaxPollingInterval Um baixo valor para garantir que os métodos de fila são

desencadeados imediatamente.
Singleton.ListenerLockPeriod 15 segundos para ajudar no rápido desenvolvimento

iterativo.
O processo de ativação do modo de desenvolvimento depende da versão SDK.

Versão 3. x
Versão 3. x usa as APIs core ASP.NET padrão. Ligue para o UseEnvironment método do HostBuilder caso. Passe
uma corda chamada development , como neste exemplo:
{
builder.UseEnvironment("development");
{
});
using (host)
{
}
}
Versão 2. x
A JobHostConfiguration classe tem um método que permite o modo de UseDevelopmentSettings
desenvolvimento. O exemplo a seguir mostra como utilizar as definições de desenvolvimento. Para fazer
config.IsDevelopment retorno quando for executado true localmente, deslote uma variável ambiental local com
AzureWebJobsEnv o valor Development .
static void Main()

{
config = new JobHostConfiguration();
if (config.IsDevelopment)
{
config.UseDevelopmentSettings();
}
var host = new JobHost(config);

host.RunAndBlock();
}
Gestão de ligações simultâneas (versão 2.* x*)

Na versão 3. x, o limite de ligação predefinido às ligações infinitas. Se por alguma razão precisar de alterar este
limite, pode utilizar a MaxConnectionsPerServer propriedade da WinHttpHandler classe.
Na versão 2. x, controla o número de ligações simultâneas a um anfitrião utilizando o
ServicePointManager.DefaultConnectionLimit API. Em 2. x, deve aumentar este valor a partir do padrão de 2 antes
de iniciar o seu anfitrião WebJobs.
Todos os pedidos HTTP de saída que escorria a partir de uma função utilizando HttpClient o fluxo através
ServicePointManager . Depois de atingir o valor DefaultConnectionLimit definido, ServicePointManager inicia os
pedidos de fila antes de os enviar. Suponha que o seu DefaultConnectionLimit está definido para 2 e o seu código
faz 1.000 pedidos HTTP. Inicialmente, apenas dois pedidos são permitidos através do SO. Os outros 998 estão na
fila até que haja espaço para eles. Isso significa que o seu HttpClient pode ter feito o tempo de ô-out porque
parece ter feito o pedido, mas o pedido nunca foi enviado pelo SO para o servidor de destino. Por isso, pode ver
um comportamento que não parece fazer sentido: o seu local HttpClient está a demorar 10 segundos a
completar um pedido, mas o seu serviço está a devolver todos os pedidos em 200 ms.
O valor padrão para aplicações ASP.NET é Int32.MaxValue , e é provável que funcione bem para webJobs em
execução em um Plano de Serviço de Aplicações Básica ou superior. Os WebJobs normalmente precisam da
definição Always On, e isso é suportado apenas por Planos básicos e superiores de serviço de aplicações.
Se o seu WebJob estiver a funcionar num Plano de Serviço de Aplicações Gratuitas ou Partilhadas, a sua aplicação
é restringida pela caixa de areia do Serviço de Aplicações, que atualmente tem um limite de ligação de 300. Com
um limite de ligação não ServicePointManager vinculado, é mais provável que o limiar de ligação da caixa de areia
seja atingido e o site seja desligado. Nesse caso, a fixação DefaultConnectionLimit para algo mais baixo, como 50
ou 100, pode impedir que isso aconteça e ainda permitir uma produção suficiente.
A definição deve ser configurada antes de serem feitos quaisquer pedidos HTTP. Por esta razão, o anfitrião
WebJobs não deve ajustar a definição automaticamente. Pode haver pedidos HTTP que ocorrem antes do início
do hospedeiro, o que pode levar a um comportamento inesperado. A melhor abordagem é definir o valor
imediatamente no seu Main método antes de JobHost rubricar, como mostrado aqui:

{
// Set this immediately so that it's used by all requests.
ServicePointManager.DefaultConnectionLimit = Int32.MaxValue;
var host = new JobHost();

host.RunAndBlock();
}
Acionadores
As funções devem ser métodos públicos e devem ter um atributo de gatilho ou o NoAutomaticTrigger atributo.
Gatilhos automáticos
Os gatilhos automáticos chamam uma função em resposta a um evento. Considere este exemplo de uma função
que é desencadeada por uma mensagem adicionada ao armazenamento da Fila Azure. Responde lendo uma
bolha do armazenamento de Azure Blob:
public static void Run(

[QueueTrigger("myqueue-items")] string myQueueItem,
[Blob("samples-workitems/{queueTrigger}", FileAccess.Read)] Stream myBlob,
ILogger log)
{
log.LogInformation($"BlobInput processed blob\n Name:{myQueueItem} \n Size: {myBlob.Length} bytes");
}
O QueueTrigger atributo diz ao tempo de execução para ligar para a função sempre que uma mensagem de fila
aparece na myqueue-items fila. O Blob atributo diz ao tempo de execução para utilizar a mensagem de fila para
ler uma bolha no recipiente de trabalho de amostra. O nome do item blob no samples-workitems recipiente é
obtido diretamente a partir do gatilho da fila como expressão de encadernação {queueTrigger} ().
NOTE
Gatilhos manuais
Para ativar uma função manualmente, utilize o NoAutomaticTrigger atributo, como mostrado aqui:
[NoAutomaticTrigger]
public static void CreateQueueMessage(
ILogger logger,
string value,
[Queue("outputqueue")] out string message)
{
message = value;
logger.LogInformation("Creating queue message: ", message);
}
O processo de ativação manual da função depende da versão SDK.

Versão 3. x
static async Task Main(string[] args)

{
{
});
using (host)
{
var jobHost = host.Services.GetService(typeof(IJobHost)) as JobHost;
var inputs = new Dictionary<string, object>
{
{ "value", "Hello world!" }
};
await host.StartAsync();
await jobHost.CallAsync("CreateQueueMessage", inputs);
await host.StopAsync();
}
}
Versão 2. x

{
JobHost host = new JobHost();
host.Call(typeof(Program).GetMethod("CreateQueueMessage"), new { value = "Hello world!" });
}
Encadernações de entrada e saída

As ligações de entrada fornecem uma forma declarativa de disponibilizar dados de Azure ou serviços de terceiros
ao seu código. As ligações de saída fornecem uma forma de atualizar os dados. O artigo Get start mostra um
exemplo de cada um.
Pode utilizar um valor de retorno de método para uma ligação de saída aplicando o atributo ao valor de retorno
do método. Veja o exemplo na Utilização do valor de retorno da função Azure.
Tipos de ligação
O processo de instalação e gestão de tipos de ligação depende se está a utilizar a versão 3. x ou versão 2. x do
SDK. Pode encontrar a embalagem para instalar para um tipo de encadernação específico na secção "Pacotes" do
artigo de referênciado tipo de ligação Azure Functions . Uma exceção é o gatilho de Ficheiros e a ligação (para o
sistema de ficheiros local), que não é suportado por Funções Azure.
Versão 3. x
Na versão 3. x, as ligações de armazenamento estão incluídas na Microsoft.Azure.WebJobs.Extensions.Storage
embalagem. Ligue para o AddAzureStorage método de extensão ConfigureWebJobs no método, como mostrado
aqui:

{
{
});
using (host)
{
}
}
Para utilizar outros tipos de gatilho e de ligação, instale o pacote NuGet que os contém e chame o Add<binding>
método de extensão implementado na extensão. Por exemplo, se quiser utilizar uma ligação DB Azure Cosmos,
instale Microsoft.Azure.WebJobs.Extensions.CosmosDB e AddCosmosDB ligue, como este:

{
{
b.AddCosmosDB();
});
using (host)
{
}
}
Para utilizar o gatilho do Temporizador ou a ligação ficheiros, que fazem parte dos serviços essenciais, ligue para
os AddTimers métodos ou AddFiles extensões, respectivamente.
Versão 2. x
Estes tipos de gatilho e de ligação estão incluídos na versão 2. x do Microsoft.Azure.WebJobs pacote:
Armazenamento de blobs
Armazenamento de filas
Table Storage
Para utilizar outros tipos de gatilho e de ligação, instale o pacote NuGet que os contém e chame um Use<binding>
método no JobHostConfiguration objeto. Por exemplo, se pretender utilizar um gatilho do Temporizador, instale
Microsoft.Azure.WebJobs.Extensions e ligue UseTimers o Main método, como mostrado aqui:
static void Main()
{
config.UseTimers();
host.RunAndBlock();
}
Para utilizar a ligação dos Ficheiros, instale Microsoft.Azure.WebJobs.Extensions e ligue UseFiles .

ExecuçãoContexto
WebJobs permite-lhe ligar-se a ExecutionContext um . Com esta ligação, pode aceder ao ExecutionContext como
parâmetro na sua assinatura de função. Por exemplo, o seguinte código utiliza o objeto de contexto para aceder
ao ID de invocação, que pode utilizar para correlacionar todos os registos produzidos por uma determinada
invocação de função.
public class Functions

{
public static void ProcessQueueMessage([QueueTrigger("queue")] string message,
ExecutionContext executionContext,
ILogger logger)
{
logger.LogInformation($"{message}\n{executionContext.InvocationId}");
}
}
O processo de ligação ao ExecutionContext do sdk depende da sua versão SDK.

Versão 3. x
Ligue para o AddExecutionContextBinding método de extensão ConfigureWebJobs no método, como mostrado
aqui:

{
{
b.AddExecutionContextBinding();
});
using (host)
{
}
}
Versão 2. x
O Microsoft.Azure.WebJobs.Extensions pacote mencionado anteriormente também fornece um tipo especial de
encadernação que você pode registar chamando o UseCore método. Esta ligação permite definir um
ExecutionContext parâmetro na sua assinatura de função, que está ativado desta forma:
class Program
{
static void Main()
{
config.UseCore();
host.RunAndBlock();
}
}
Configuração de encadernação
Pode configurar o comportamento de alguns gatilhos e encadernações. O processo de configuração depende da
versão SDK.
Versão 3. x : Definir a configuração quando o Add<Binding> método for chamado ConfigureWebJobs .
Versão 2. x : Definir a configuração definindo as propriedades num objeto de configuração para o que passa
JobHost .
Estas definições específicas de encadernação são equivalentes às definições no ficheiro do projeto host.json em
Funções Azure.
Pode configurar as seguintes ligações:
Gatilho Azure CosmosDB
Gatilho de Centros de Eventos
Acionador do armazenamento de filas
Ligação SendGrid
Gatilho do ônibus de serviço
Configuração do gatilho Azure CosmosDB (versão 3).* x*)
Este exemplo mostra como configurar o gatilho Azure Cosmos DB:

{
{
b.AddCosmosDB(a =>
{
a.ConnectionMode = ConnectionMode.Gateway;
a.Protocol = Protocol.Https;
a.LeaseOptions.LeasePrefix = "prefix1";
});
});
using (host)
{
}
}
Para mais detalhes, consulte o artigo de vindca Azure CosmosDB.

Configuração do gatilho do Event Hubs (versão 3).* x*)
Este exemplo mostra como configurar o gatilho do Event Hubs:
{
{
b.AddEventHubs(a =>
{
a.BatchCheckpointFrequency = 5;
a.EventProcessorOptions.MaxBatchSize = 256;
a.EventProcessorOptions.PrefetchCount = 512;
});
});
using (host)
{
}
}
Para mais detalhes, consulte o artigo de vindcação do Event Hubs.

Configuração do gatilho de armazenamento de fila
Estes exemplos mostram como configurar o gatilho de armazenamento da fila:
Versão 3. x

{
{
b.AddAzureStorage(a => {
a.BatchSize = 8;
a.NewBatchThreshold = 4;
a.MaxDequeueCount = 4;
a.MaxPollingInterval = TimeSpan.FromSeconds(15);
});
});
using (host)
{
}
}
Para mais detalhes, consulte o artigo de encadernação de armazenamento da fila.

Versão 2. x

{
config.Queues.BatchSize = 8;
config.Queues.NewBatchThreshold = 4;
config.Queues.MaxDequeueCount = 4;
config.Queues.MaxPollingInterval = TimeSpan.FromSeconds(15);
host.RunAndBlock();
}
Para mais detalhes, consulte a referência host.json v1.x.
Configuração de ligação SendGrid (versão 3.* x*)
Este exemplo mostra como configurar a ligação de saída SendGrid:

{
{
b.AddSendGrid(a =>
{
a.FromAddress.Email = "samples@functions.com";
a.FromAddress.Name = "Azure Functions";
});
});
using (host)
{
}
}
Para mais detalhes, consulte o artigo de ligação enviar a Golh.

Configuração do gatilho do autocarro de serviço (versão 3.* x*)
Este exemplo mostra como configurar o gatilho do Service Bus:

{
{
b.AddServiceBus(sbOptions =>
{
sbOptions.MessageHandlerOptions.AutoComplete = true;
sbOptions.MessageHandlerOptions.MaxConcurrentCalls = 16;
});
});
using (host)
{
}
}
Para mais detalhes, consulte o artigo de vindca de serviço do Service Bus.

Configuração para outras encadernações
Alguns tipos de gatilho e de ligação definem os seus próprios tipos de configuração personalizada. Por exemplo, o
gatilho do Ficheiro permite especificar o caminho raiz a monitorizar, como nestes exemplos:
Versão 3. x
{
{
b.AddFiles(a => a.RootPath = @"c:\data\import");
});
using (host)
{
}
}
Versão 2. x
static void Main()

{
var filesConfig = new FilesConfiguration
{
RootPath = @"c:\data\import"
};
config.UseFiles(filesConfig);
host.RunAndBlock();
}
Expressões de enlace
Nos parâmetros de construção de atributos, pode utilizar expressões que se resolvem a valores de várias fontes.
Por exemplo, no seguinte código, o caminho para o BlobTrigger atributo cria uma expressão chamada filename
. Quando utilizado para a ligação de saída, filename resolve-se o nome da bolha de desencadeamento.
public static void CreateThumbnail(

[BlobTrigger("sample-images/{filename}")] Stream image,
[Blob("sample-images-sm/{filename}", FileAccess.Write)] Stream imageSmall,
string filename,
ILogger logger)
{
logger.Info($"Blob trigger processing: {filename}");
// ...
}
Para obter mais informações sobre expressões de encadernação, consulte expressões e padrões de ligação na
documentação Azure Functions.
Expressões de encadernação personalizadas
Por vezes, pretende especificar um nome de fila, um nome de bolha ou recipiente, ou um nome de mesa em
código em vez de codificar duramente. Por exemplo, é possível especificar o nome da fila para o QueueTrigger
atributo num ficheiro de configuração ou variável ambiental.
Podes fazer isso passando um NameResolver objeto para o JobHostConfiguration objeto. Você inclui espaços
reservados nos parâmetros de gatilho ou atributo de ligação, e o seu NameResolver código fornece os valores
reais a serem usados no lugar desses espaços reservados. Identifica-se os espaços reservados ao rodeá-los com
por cento (%) sinais, como mostrado aqui:
public static void WriteLog([QueueTrigger("%logqueue%")] string logMessage)
{
Console.WriteLine(logMessage);
}
Este código permite-lhe utilizar uma fila nomeada logqueuetest no ambiente de teste e uma nomeada em
logqueueprod produção. Em vez de um nome de fila codificado, especifica o nome de uma entrada na
appSettings coleção.
Há um padrão NameResolver que faz efeito se não fornecer um personalizado. O padrão obtém valores a partir de
configurações de aplicações ou variáveis ambientais.
A sua NameResolver turma obtém o nome da appSettings fila, como mostrado aqui:
public class CustomNameResolver : INameResolver

{
public string Resolve(string name)
{
return ConfigurationManager.AppSettings[name].ToString();
}
}
Versão 3. x
Configura o resolver utilizando a injeção de dependência. Estas amostras requerem a seguinte using declaração:
using Microsoft.Extensions.DependencyInjection;
Adicione o resolver chamando o método de ConfigureServices HostBuilder extensão, como neste exemplo:

{
var resolver = new CustomNameResolver();
{
});
builder.ConfigureServices(s => s.AddSingleton<INameResolver>(resolver));
using (host)
{
}
}
Versão 2. x
Passe a sua NameResolver classe para o JobHost objeto, como mostrado aqui:

{
config.NameResolver = new CustomNameResolver();
host.RunAndBlock();
}
A Azure Functions implementa INameResolver para obter valores a partir das definições de aplicações, como
mostra o exemplo. Quando utilizar o WebJobs SDK diretamente, pode escrever uma implementação
personalizada que obtém valores de substituição de espaços reservados a partir de qualquer fonte que prefira.
Encadernação no tempo de execução

Se precisar de fazer algum trabalho na sua função antes de utilizar um atributo de encadernação como Queue ,
ou , pode utilizar a Blob Table IBinder interface.
O exemplo a seguir pega numa mensagem de fila de entrada e cria uma nova mensagem com o mesmo
conteúdo numa fila de saída. O nome da fila de saída é definido por código no corpo da função.
public static void CreateQueueMessage(

[QueueTrigger("inputqueue")] string queueMessage,
IBinder binder)
{
string outputQueueName = "outputqueue" + DateTime.Now.Month.ToString();
QueueAttribute queueAttribute = new QueueAttribute(outputQueueName);
CloudQueue outputQueue = binder.Bind<CloudQueue>(queueAttribute);
outputQueue.AddMessageAsync(new CloudQueueMessage(queueMessage));
}
Para obter mais informações, consulte Binding at runtime na documentação Azure Functions.
Informações vinculativas de referência

A documentação Azure Functions fornece informações de referência sobre cada tipo de encadernação. Encontrará
as seguintes informações em cada artigo de referência vinculativo. (Este exemplo baseia-se na fila de
armazenamento.)
Pacotes. O pacote que precisa de instalar para incluir suporte para a encadernação num projeto WebJobs SDK.
Exemplos. Amostras de código. O exemplo da biblioteca de classes C# aplica-se ao WebJobs SDK. Apenas
omita o FunctionName atributo.
Atributos. Os atributos a utilizar para o tipo de encadernação.
Configuração. Explicações das propriedades do atributo e dos parâmetros do construtor.
Utilização. Os tipos a que se pode ligar e informações sobre como funciona a ligação. Por exemplo: algoritmo
de sondagens, processamento de fila venenosa.
Para obter uma lista de artigos de referência vinculativos, consulte "Encadernações suportadas" no artigo de
gatilhos e encadernações para funções azure. Nessa lista, as ligações HTTP, Webhooks e Event Grid são
suportadas apenas por Funções Azure, e não pelo WebJobs SDK.
Atribuir desativar
O Disable atributo permite-lhe controlar se uma função pode ser ativada.
No exemplo seguinte, se a definição da aplicação Disable_TestJob tiver um valor ou 1 True (caso insensível), a
função não será executada. Nesse caso, o tempo de execução cria uma função de mensagem de registo
'Funções.TestJob' é desativada.
[Disable("Disable_TestJob")]
public static void TestJob([QueueTrigger("testqueue2")] string message)
{
Console.WriteLine("Function with Disable attribute executed!");
}
Quando altera os valores de definição de aplicações no portal Azure, o WebJob reinicia para recolher a nova
definição.
O atributo pode ser declarado ao nível do parâmetro, método ou classe. O nome de definição também pode
conter expressões de encadernação.
Atributo timeout
O Timeout atributo faz com que uma função seja cancelada se não terminar dentro de um determinado período
de tempo. No exemplo seguinte, a função funcionaria durante um dia sem o atributo Timeout. O intervalo faz
com que a função seja cancelada após 15 segundos.
[Timeout("00:00:15")]
public static async Task TimeoutJob(
[QueueTrigger("testqueue2")] string message,
CancellationToken token,
TextWriter log)
{
await log.WriteLineAsync("Job starting");
await Task.Delay(TimeSpan.FromDays(1), token);
await log.WriteLineAsync("Job completed");
}
Pode aplicar o atributo Timeout ao nível da classe ou do método, e pode especificar um tempo limite global
utilizando JobHostConfiguration.FunctionTimeout . Os intervalos de tempo de nível de classe ou de nível
metodológico substituem os intervalos globais.
Atributo Singleton
O Singleton atributo garante que apenas uma instância de uma função é executado, mesmo quando existem
múltiplas instâncias da aplicação web anfitriã. Fá-lo utilizando o bloqueio distribuído.
Neste exemplo, apenas um único caso da ProcessImage função funciona a qualquer momento:
[Singleton]
public static async Task ProcessImage([BlobTrigger("images")] Stream image)
{
// Process the image.
}
SingletonMode.Listener
Alguns gatilhos têm apoio integrado para a gestão da concuência:
QueueTrigger . Definir JobHostConfiguration.Queues.BatchSize para 1 .
Ser viceBusTrigger . Definir ServiceBusConfiguration.MessageOptions.MaxConcurrentCalls para 1 .
FileTrigger . Definir FileProcessor.MaxDegreeOfParallelism para 1 .
Pode utilizar estas definições para garantir que a sua função funciona como singleton num único caso. Para
garantir que apenas uma instância da função está a funcionar quando a aplicação web se escala para várias
instâncias, aplique um bloqueio singleton de nível de ouvinte na função
[Singleton(Mode = SingletonMode.Listener)] (). As fechaduras dos ouvintes são adquiridas quando o JobHost
começa. Se três casos de escala começarem todos ao mesmo tempo, apenas uma das instâncias adquire o
bloqueio e apenas um ouvinte começa.
NOTE
Consulte este GitHub Repo para saber mais sobre o funcionamento do SingletonMode.Function.
Valores de âmbito
Pode especificar uma expressão/valor de âmbito num singleton. A expressão/valor garante que todas as
execuções da função num âmbito específico serão serializadas. A implementação de mais bloqueio granular desta
forma pode permitir algum nível de paralelismo para a sua função, ao mesmo tempo que serializa outras
invocações ditadas pelas suas necessidades. Por exemplo, no seguinte código, a expressão de âmbito liga-se ao
Region valor da mensagem de entrada. Quando a fila contém três mensagens nas regiões Leste, Leste e Oeste,
respectivamente, as mensagens que têm região Leste são executadas em série enquanto a mensagem com a
região Oeste é executada em paralelo com as do Leste.
[Singleton("{Region}")]
public static async Task ProcessWorkItem([QueueTrigger("workitems")] WorkItem workItem)
{
// Process the work item.
}
public class WorkItem

{
public int ID { get; set; }
public string Region { get; set; }
public int Category { get; set; }
public string Description { get; set; }
}
SingletonScope.Host
O âmbito padrão para uma fechadura SingletonScope.Function é, o que significa que o âmbito de bloqueio (o
caminho de locação blob) está ligado ao nome de função totalmente qualificado. Para bloquear as funções,
especifique SingletonScope.Host e use um nome de identificação de âmbito que seja o mesmo em todas as
funções que não pretende executar simultaneamente. No exemplo seguinte, apenas um caso de AddItem ou corre
de cada RemoveItem vez:
[Singleton("ItemsLock", SingletonScope.Host)]
public static void AddItem([QueueTrigger("add-item")] string message)
{
// Perform the add operation.
}
[Singleton("ItemsLock", SingletonScope.Host)]
public static void RemoveItem([QueueTrigger("remove-item")] string message)
{
// Perform the remove operation.
}
Ver bolhas de arrendamento

O WebJobs SDK utiliza locações blob Azure sob as capas para implementar bloqueio distribuído. As bolhas de
locação utilizadas pela Singleton podem ser encontradas azure-webjobs-host no recipiente na conta de
armazenamento sob o caminho AzureWebJobsStorage "fechaduras". Por exemplo, o caminho da bolha de
arrendamento para o primeiro ProcessImage exemplo mostrado anteriormente pode ser
locks/061851c758f04938a4426aa9ab3869c0/WebJobs.Functions.ProcessImage . Todos os caminhos incluem o ID
JobHost, neste caso 061851c758f04938a426aaaa9ab3869c0.
Funções assínc
Para obter informações sobre como codificar funções async, consulte a documentação do Azure Functions.
Fichas de cancelamento
Para obter informações sobre como lidar com fichas de cancelamento, consulte a documentação do Azure
Functions sobre fichas de cancelamento e paragem graciosa.
Múltiplas instâncias
Se a sua aplicação web funcionar em várias instâncias, um WebJob contínuo funciona em cada instância, ouvindo
os gatilhos e as funções de chamada. As várias ligações ao gatilho são projetadas para partilhar eficientemente o
trabalho colaborativamente em todos os casos, de modo que a escala para mais instâncias permite-lhe lidar com
mais carga.
Embora alguns gatilhos possam resultar em duplo processamento, os gatilhos de armazenamento de fila e bolhas
impedem automaticamente uma função de processar uma mensagem de fila ou uma bolha mais de uma vez.
Para obter mais informações, consulte design para obter uma entrada idêntica na documentação Azure Functions.
O gatilho do temporizador assegura automaticamente que apenas uma instância do temporizador é executado,
para que não obtenha mais do que uma instância de função a funcionar numa determinada hora programada.
Se quiser garantir que apenas uma instância de uma função é executado mesmo quando existem múltiplas
instâncias da aplicação web anfitriã, pode usar o Singleton atributo.
Filtros
Os Filtros de Função (pré-visualização) fornecem uma forma de personalizar o pipeline de execução WebJobs
com a sua própria lógica. Os filtros são semelhantes aos filtros do núcleo ASP.NET. Pode implementá-los como
atributos declarativos que são aplicados às suas funções ou classes. Para obter mais informações, consulte filtros
de funções.
Início de sessão e monitorização

Recomendamos o quadro de exploração madeireira que foi desenvolvido para ASP.NET. O artigo "Get started"
mostra como usá-lo.
Filtragem de registos
Cada registo criado por um ILogger caso tem um associado e Category Level . LogLevel é uma enumeração, e
o código inteiro indica importância relativa:
N ÍVEL DE REGISTO C Ó DIGO
Rastreio 0
Depurar 1
Informações 2
Aviso 3
Erro 4
N ÍVEL DE REGISTO C Ó DIGO
Crítico 5
Nenhum 6
Pode filtrar independentemente cada categoria para um determinado LogLevel . Por exemplo, é melhor ver todos
os registos para processamento de gatilhos blob, mas apenas Error e mais alto para tudo o resto.
Versão 3. x
Versão 3. x do SDK depende da filtragem incorporada em .NET Core. A LogCategories classe permite definir
categorias para funções específicas, gatilhos ou utilizadores. Também define filtros para estados de acolhimento
específicos, como Startup e Results . Isto permite-lhe afinar a saída de registo. Se não for encontrada
correspondência nas categorias definidas, o filtro volta ao valor ao Default decidir filtrar a mensagem.
LogCategories requer a seguinte declaração:
using Microsoft.Azure.WebJobs.Logging;
O exemplo a seguir constrói um filtro que, por defeito, filtra todos os registos ao Warning nível. As Function
results categorias e categorias (equivalente à Host.Results versão 2.* x*) são filtrados ao Error nível. O filtro
compara a categoria atual a todos os níveis registados no LogCategories caso e escolhe a correspondência mais
longa. Isto significa que o Debug nível registado para Host.Triggers fósforos Host.Triggers.Queue ou
Host.Triggers.Blob . Isto permite-lhe controlar categorias mais amplas sem precisar de adicionar cada uma
delas.

{
{
});
builder.ConfigureLogging(logging =>
{
logging.SetMinimumLevel(LogLevel.Warning);
logging.AddFilter("Function", LogLevel.Error);
logging.AddFilter(LogCategories.CreateFunctionCategory("MySpecificFunctionName"),
LogLevel.Debug);
logging.AddFilter(LogCategories.Results, LogLevel.Error);
logging.AddFilter("Host.Triggers", LogLevel.Debug);
});
using (host)
{
}
}
Versão 2. x
Na versão 2. x do SDK, usa-se a LogCategoryFilter classe para controlar a filtragem. A LogCategoryFilter
propriedade tem um valor inicial de , o que significa que Default Information quaisquer mensagens no
Information , , ou Warning Error Critical níveis são registados, mas quaisquer mensagens nos Debug níveis
ou Trace níveis são filtradas.
Como LogCategories na versão 3.* x*, a CategoryLevels propriedade permite especificar níveis de registo para
categorias específicas para que possa afinar a saída de registo. Se não for encontrada correspondência dentro do
CategoryLevels dicionário, o filtro volta ao valor ao Default decidir se filtra a mensagem.
O exemplo a seguir constrói um filtro que por predefinição filtra todos os registos ao Warning nível. As Function
Host.Results categorias e categorias são filtradas ao Error nível. LogCategoryFilter O compara a categoria
atual a todos os CategoryLevels inscritos e escolhe o jogo mais longo. Assim, o Debug nível registado
Host.Triggers para irá corresponder Host.Triggers.Queue ou Host.Triggers.Blob . Isto permite-lhe controlar
categorias mais amplas sem precisar de adicionar cada uma delas.
var filter = new LogCategoryFilter();

filter.DefaultLevel = LogLevel.Warning;
filter.CategoryLevels[LogCategories.Function] = LogLevel.Error;
filter.CategoryLevels[LogCategories.Results] = LogLevel.Error;
filter.CategoryLevels["Host.Triggers"] = LogLevel.Debug;
config.LoggerFactory = new LoggerFactory()

.AddApplicationInsights(instrumentationKey, filter.Filter)
.AddConsole(filter.Filter);
Telemetria personalizada para Insights de Aplicações

O processo de implementação de telemetria personalizada para Insights de Aplicação depende da versão SDK.
Para aprender a configurar insights de aplicações, consulte Adicionar Insights de Aplicação registando.
Versão 3. x
Porque a versão 3. x do WebJobs SDK conta com o hospedeiro genérico .NET Core, uma fábrica de telemetria
personalizada já não é fornecida. Mas pode adicionar telemetria personalizada ao oleoduto usando a injeção de
dependência. Os exemplos desta secção requerem as seguintes using declarações:
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.ApplicationInsights.Channel;
A seguinte implementação personalizada ITelemetryInitializer permite adicionar a sua própria ao ITelemetry

padrão TelemetryConfiguration .
internal class CustomTelemetryInitializer : ITelemetryInitializer

{
public void Initialize(ITelemetry telemetry)
{
// Do something with telemetry.
}
}
Ligue ConfigureServices para o construtor para adicionar o seu costume ao ITelemetryInitializer oleoduto.
{
{
});
{
// Add logging providers.
b.AddConsole();
// If this key exists in any config, use it to enable Application Insights.

string appInsightsKey = context.Configuration["APPINSIGHTS_INSTRUMENTATIONKEY"];
if (!string.IsNullOrEmpty(appInsightsKey))
{
// This uses the options callback to explicitly set the instrumentation key.
b.AddApplicationInsights(o => o.InstrumentationKey = appInsightsKey);
}
});
builder.ConfigureServices(services =>
{
services.AddSingleton<ITelemetryInitializer, CustomTelemetryInitializer>();
});
using (host)
{
}
}
Quando o TelemetryConfiguration é construído, todos os tipos ITelemetryInitializer registados de estão

incluídos. Para saber mais, consulte a App Insights API para eventos e métricas personalizados.
Na versão 3. x, já não é preciso descarregar o TelemetryClient quando o hospedeiro parar. O sistema de injeção
de dependência .NET Core elimina automaticamente o ApplicationInsightsLoggerProvider registado, que elimina
o TelemetryClient .
Versão 2. x
Na versão 2. x, criado TelemetryClient internamente pelo fornecedor application insights para as utilizações
webJobs SDK ServerTelemetryChannel . Quando o ponto final do Application Insights não está disponível ou a
estrangular os pedidos de entrada, este canal guarda pedidos no sistema de ficheiros da aplicação web e reenvia-
os mais tarde.
O TelemetryClienté criado por uma classe que ITelemetryClientFactory implementa. Por padrão, este é o
DefaultTelemetryClientFactory .
Se quiser modificar qualquer parte do pipeline Application Insights, pode fornecer o seu próprio
ITelemetryClientFactory , e o anfitrião utilizará a sua classe para construir um TelemetryClient . Por exemplo,
este código substitui DefaultTelemetryClientFactory para modificar uma propriedade ServerTelemetryChannel de:
private class CustomTelemetryClientFactory : DefaultTelemetryClientFactory
{
public CustomTelemetryClientFactory(string instrumentationKey, Func<string, LogLevel, bool> filter)
: base(instrumentationKey, new SamplingPercentageEstimatorSettings(), filter)
{
}
protected override ITelemetryChannel CreateTelemetryChannel()

{
ServerTelemetryChannel channel = new ServerTelemetryChannel();
// Change the default from 30 seconds to 15 seconds.

channel.MaxTelemetryBufferDelay = TimeSpan.FromSeconds(15);
return channel;
}
}
O SamplingPercentageEstimatorSettings objeto configura a amostragem adaptativa. Isto significa que em certos

cenários de grande volume, o Applications Insights envia um subconjunto selecionado de dados de telemetria
para o servidor.
Depois de criar a fábrica de telemetria, passe-a para o fornecedor de registo de Insights de Aplicação:
var clientFactory = new CustomTelemetryClientFactory(instrumentationKey, filter.Filter);
config.LoggerFactory = new LoggerFactory()

.AddApplicationInsights(clientFactory);
Próximos passos
Este artigo forneceu código snippets que mostram como lidar com cenários comuns para trabalhar com o
WebJobs SDK. Para obter amostras completas, consulte amostras azure-webjobs-sdk.
Subscrição do Azure e limites, quotas e limitações do
serviço (Azure subscription and service limits, quotas,
and constraints)
Este documento enumera alguns dos limites mais comuns do Microsoft Azure, que também são por vezes
chamados de quotas.
Para saber mais sobre os preços da Azure, consulte a visão geral dos preços do Azure. Aí, pode estimar os seus
custos utilizando a calculadora de preços. Também pode ir à página de detalhes de preços para um determinado
serviço, por exemplo, VMs Windows. Para obter dicas para ajudar a gerir os seus custos, consulte Prevenir custos
inesperados com faturação da Azure e gestão de custos.
Limites de gestão
NOTE
Alguns serviços têm limites ajustáveis.
Quando um serviço não tem limites ajustáveis, as seguintes tabelas utilizam o limite do cabeçalho . Nesses casos, o
incumprimento e os limites máximos são os mesmos.
Quando o limite pode ser ajustado, as tabelas incluem limite de predefinição e cabeçalhos limite máximos. O limite
pode ser elevado acima do limite de incumprimento, mas não acima do limite máximo.
Se pretender elevar o limite ou quota acima do limite por defeito, abra gratuitamente um pedido de apoio ao cliente online.
As assinaturas de teste gratuito não são elegíveis para aumentos de limites ou quotas. Se tiver uma subscrição de
Teste Gratuito,pode fazer upgrade para uma subscrição Pay-As-You-Go. Para obter mais informações, consulte a
atualização da subscrição do Azure Free Trial para uma subscrição Pay-As-You-Go e a subscrição de teste gratuito
FAQ.
Alguns limites são geridos a nível regional.
Vamos usar as quotas vCPU como exemplo. Para solicitar um aumento de quota com apoio para vCPUs, você deve
decidir quantos vCPUs você quer usar em que regiões. Em seguida, faça um pedido específico para quotas vCPU
do grupo de recursos Azure para os montantes e regiões que deseja. Se precisa de utilizar 30 vCPUs na Europa
Ocidental para executar a sua aplicação lá, solicite especificamente 30 vCPUs na Europa Ocidental. A sua quota
vCPU não é aumentada em nenhuma outra região, só a Europa Ocidental tem a quota de 30 vCPU.
Como resultado, decida quais as suas quotas de grupo de recursos Azure para a sua carga de trabalho em
qualquer região. Em seguida, solicite esse montante em cada região em que pretende implantar. Para obter ajuda
na forma de determinar as suas quotas atuais para regiões específicas, consulte os erros de Resolução para quotas
de recursos.
Limites gerais
Para limites de nomes de recursos, consulte as regras de nomeação e as restrições para os recursos da Azure.
Para obter informações sobre a API do Gestor de Recursos, leia e escreva limites, consulte os pedidos do Gestor de
Recursos Throttling.
Limites do grupo de gestão
Os seguintes limites aplicam-se aos grupos de gestão.
REC URSO L IM IT E
Grupos de gestão por diretório 10,000
Assinaturas por grupo de gestão Ilimitado.
Níveis de hierarquia do grupo de gestão Nível raiz mais 6 níveis1
Grupo de gestão de pais diretos por grupo de gestão Um
Implementações de nível de grupo de gestão por localização 8002
1 Os 6 níveis não incluem o nível de subscrição.

2 Se atingir
o limite de 800 implementações, elimine as implementações da história que já não são necessárias.
Para eliminar as implementações de nível de grupo de gestão, utilize a remoção de remove-
AzManagementGroupDeployment ou az deployment mg eliminar.
Limites da subscrição
Os seguintes limites aplicam-se quando utiliza grupos de recursos Azure Resource Manager e Azure.
REC URSO L IM IT E
Assinaturas por inquilino do Diretório Ativo Azure Ilimitado.
Coadministradores por subscrição Ilimitado.
Grupos de recursos por subscrição 980
Tamanho do pedido do Gestor de Recursos Azure API 4.194.304 bytes.
Etiquetas por subscrição1 50
Cálculos de etiquetas únicos por subscrição1 10,000
Implementações de nível de subscrição por localização 8002
1 Pode aplicar até 50 tags diretamente a uma subscrição. No entanto, a subscrição pode conter um número
ilimitado de tags que são aplicadas a grupos de recursos e recursos dentro da subscrição. O número de etiquetas
por grupo de recursos ou recursos é limitado a 50. O Gestor de Recursos devolve uma lista de nomes e valores
únicos na subscrição apenas quando o número de tags for de 10.000 ou menos. Ainda pode encontrar um recurso
por etiqueta quando o número ultrapassa os 10.000.
2 Se atingir
o limite de 800 implementações, elimine as implementações da história que já não são necessárias.
Para eliminar as implementações de nível de subscrição, utilize a eliminação de remove-azDeployment ou az
implementação sub eliminar.
Limites de grupo de recursos
REC URSO L IM IT E
Recursos por grupo de recursos Os recursos não são limitados por grupo de recursos. Em vez
disso, são limitados por tipo de recursos num grupo de
recursos. Veja a próxima fila.
Recursos por grupo de recursos, por tipo de recurso 800 - Alguns tipos de recursos podem exceder o limite de
800. Ver Recursos não limitados a 800 instâncias por grupo de
recursos.
Implementações por grupo de recursos no histórico de 8001

implantação
Recursos por implantação 800
Bloqueios de gestão por âmbito único 20
Número de tags por recurso ou grupo de recursos 50
Comprimento da chave da etiqueta 512
Comprimento do valor da etiqueta 256
1 A partirde junho de 2020, as implementações serão automaticamente eliminadas do histórico à medida que se
aproxima do limite. Excluir uma entrada do histórico de implantação não afeta os recursos implantados. Para obter
mais informações, consulte as supressões automáticas do histórico de implantação.
Limites de modelo
VA LO R L IM IT E
Parâmetros 256
Variáveis 256
Recursos (incluindo a contagem de cópias) 800
Saídas 64
Expressão do modelo 24.576 chars
Recursos em modelos exportados 200
Tamanho do modelo 4 MB
Tamanho do arquivo do parâmetro 64 KB
Pode exceder alguns limites de modelo usando um modelo aninhado. Para obter mais informações, consulte Utilize
modelos ligados quando implementar recursos Azure. Para reduzir o número de parâmetros, variáveis ou saídas,
pode combinar vários valores num objeto. Para obter mais informações, consulte os Objetos como parâmetros.
Limites de diretório ativo

Aqui estão as restrições de utilização e outros limites de serviço do serviço do Azure Active Directory (Azure AD).
C AT EGO RIA L IM IT E
Diretórios Um único utilizador pode pertencer a um máximo de 500

diretórios do Azure AD como membro ou convidado.
Um único utilizador pode criar um máximo de 200 diretórios.
Domínios Pode adicionar um máximo de 900 nomes de domínio gerido.

Se configurar todos os seus domínios para federação com o
Active Directory no local, pode adicionar um máximo de 450
nomes de domínio em cada diretório.
Recursos Um máximo de 50.000 recursos da AD Azure podem

ser criados num único diretório pelos utilizadores da
edição gratuita do Azure Ative Directory por padrão.
Se tiver pelo menos um domínio verificado, a quota de
serviço aD Azure padrão para a sua organização é
alargada a 300.000 recursos ad.a.. Este limite de
serviço não está relacionado com o limite de preços de
500.000 recursos na página de preços da AD Azure.
Para ir além da quota padrão, deve contactar o
Microsoft Support.
Um utilizador não administrador não pode criar mais
de 250 recursos da AD Azure. Tanto os recursos ativos
como os recursos eliminados que estão disponíveis
para restabelecer a contagem para esta quota. Apenas
os recursos ad-ad-aeliminaram que foram apagados
há menos de 30 dias estão disponíveis para restaurar.
Recursos AD Azure apagados que já não estão
disponíveis para restaurar a contagem para esta quota
no valor de um quarto durante 30 dias. Se tiver
desenvolvedores que possam exceder repetidamente
esta quota no decurso das suas funções regulares,
pode criar e atribuir uma função personalizada com
permissão para criar um número ilimitado de inscrições
de aplicações.
Extensões de esquema As extensões de tipo de cadeia podem ter até 256

carateres.
As extensões de tipo binário estão limitadas a 256
bytes.
Apenas 100 valores de extensão, em todos os tipos e
aplicações, podem ser escritos a qualquer recurso
Azure AD.
Apenas as entidades User, Group, TenantDetail, Device,
Application e ServicePrincipal podem ser expandidas
com os atributos de valor único do tipo de cadeia ou
de tipo de binário.
As extensões de esquema estão disponíveis apenas na
pré-visualização da versão 1.21 da Graph API. A
aplicação tem de ter acesso de escrita para registar
uma extensão.
Aplicações No máximo, cem utilizadores podem ser proprietários de uma

única aplicação.
Manifesto de candidatura No Manifesto de Inscrição pode adicionar um máximo de

1200 inscrições.
Grupos Um utilizador pode criar um máximo de 250 grupos

numa organização da Azure AD.
Uma organização da AD Azure pode ter um máximo
de 5000 grupos dinâmicos.
No máximo, cem utilizadores podem ser proprietários
de um único grupo.
Qualquer número de recursos da AD Azure pode ser
membro de um único grupo.
Um utilizador pode ser membro de qualquer número
de grupos.
O número de membros de um grupo que pode
sincronizar a partir do Active Directory no local para o
Azure Active Directory com o Azure AD Connect está
limitado a 50 000 membros.
Grupos Aninhados em Azure AD não são suportados
em todos os cenários
Neste momento estão os cenários apoiados com grupos

aninhados.
Um grupo pode ser adicionado como membro de
outro grupo e você pode alcançar a nidificação em
grupo.
As reclamações de membros do grupo (quando uma
aplicação é configurada para receber reclamações de
membros do grupo no token, grupos aninhados que o
utilizador inscrito é membro estão incluídos)
Acesso condicional (ao pesquisar uma política de
acesso condicional a um grupo)
Restringir o acesso ao reset de senha self-serve
Restringir quais os utilizadores que podem fazer AD
Join e registo do dispositivo
Os seguintes cenários NÃO suportam grupos aninhados:

Atribuição de funções de aplicação (atribuir grupos a
uma app é suportado, mas os grupos aninhados
dentro do grupo diretamente designado não terão
acesso), tanto para acesso como para o
provisionamento
Licenciamento baseado em grupo (atribuição de licença
automaticamente a todos os membros de um grupo)
Escritório 365 Grupos.
Proxy de Aplicações Um máximo de 500 transações por segundo por

aplicação App Proxy
Um máximo de 750 transações por segundo para a
organização Azure AD
Uma transação é definida como um único pedido de http e

resposta para um recurso único. Quando estrangulados, os
clientes receberão uma resposta de 429 (pedidos a mais).
Painel de Acesso Não existe nenhum limite para o número de aplicações

apresentado no Painel de Acesso por utilizador. Isto
aplica-se aos utilizadores aos quais foram atribuídas
licenças para o Azure AD Premium ou o Enterprise
Mobility Suite.
Um máximo de dez mosaicos de aplicação é
apresentado no Painel de Acesso para cada utilizador.
Este limite aplica-se aos utilizadores que recebem
licenças para o plano de licença Sem Acesso Azure AD.
Exemplos de mosaicos de aplicação incluem o Box,
Salesforce ou Dropbox. Este limite não se aplica às
contas de administrador.
Relatórios Pode ser visto um máximo de 1000 linhas ou transferido em

qualquer relatório. Quaisquer dados adicionais são truncados.
Unidades administrativas Um recurso Azure AD pode ser membro de no máximo 30

unidades administrativas.
Funções e permissões de administrador Um grupo não pode ser adicionado como proprietário.
Um grupo não pode ser designado para um papel.
A capacidade dos utilizadores de lerem as informações
de diretório de outros utilizadores não podem ser
restringidas fora do interruptor da organização Azure
AD para desativar o acesso de todos os utilizadores
não administradores a todas as informações de
diretório (não recomendadas). Mais informações sobre
permissões por defeito aqui.
Pode levar até 15 minutos ou assinar/assinar antes que
as adições e revogações de cargos de administração
entrem em vigor.
Limites de gestão da API

REC URSO L IM IT E
Número máximo de unidades de escala 10 por região1
Tamanho da cache 5 GiB por unidade2
Conexões recorrentes de back-end3 por autoridade HTTP 2.048 por unidade4
Tamanho máximo da resposta em cache 2 MiB
Tamanho máximo do documento de política 256 KiB5
Domínios de gateway personalizados máximos por instância 20

de serviço6
Número máximo de certificados ca por instância de serviço7 10
Número máximo de casos de serviço por subscrição8 20

REC URSO L IM IT E
Número máximo de assinaturas por exemplo de serviço8 500
Número máximo de certificados de cliente por instância de 50

serviço8
Número máximo de APIs por instância de serviço8 50
Número máximo de operações da API por instância de 1,000

serviço8
Duração total total do pedido8 30 segundos
Tamanho máximo da carga útil tamponada8 2 MiB
Tamanho9 de URL de pedido máximo 4096 bytes
Número máximo de gateways auto-hospedados10 25
1 Os limites de escala dependem do nível de preços. Para obter mais informações sobre os níveis de preços e os
seus limites de escala, consulte os preços da Gestão DaAPi.
2 O tamanho do cache por unidade depende do nível de preços. Para ver os níveis de preços e os seus limites de
escala, consulte os preços da Gestão Da API.

3 As ligações são reunidas e reutilizadas a menos que explicitamente fechadas na parte de trás.
4 Este limite é por unidade dos níveis Básico, Standard e Premium. O nível de Desenvolvimento está limitado a
1.024. Este limite não se aplica ao nível de consumo.

5 Este limite aplica-se aos níveis Básico, Standard e Premium. No nível de Consumo, o tamanho do documento
político é limitado a 4 KiB.

6 Vários domínios personalizados são suportados apenas nos níveis Developer e Premium.
7 Os certificados CA não são suportados no nível de consumo.
8 Este recurso aplica-se apenas ao nível de Consumo.
9 Aplica-se apenas ao nível de Consumo. Inclui uma corda de consulta longa até 2048 bytes.
10 Os gateways auto-hospedados são suportados apenas nos níveis Developer e Premium. O limite aplica-se ao
número de recursos de gateway auto-alojados. Para aumentar este limite, contacte o suporte. Note-se que o
número de nós (ou réplicas) associados a um recurso de gateway auto-hospedado é ilimitado no nível Premium e
limitado a um único nó no nível de Desenvolvimento.
Limites do Serviço de Aplicações

Os seguintes limites do Serviço de Aplicações incluem limites para aplicações web, aplicações móveis e aplicações
API.
REC URSO GRAT UITO PA RT IL H A DO B Á SIC O STA N DA RD P REM IUM ( V2) ISO L A DO
Aplicações 10 100 Ilimitado2 Ilimitado2 Ilimitado2 Ilimitado2

Web, móveis
ou API por
plano de
serviço de
aplicações
Azure1
Plano de 10 por região 10 por grupo 100 por 100 por 100 por 100 por grupo
serviço de de recursos grupo de grupo de grupo de de recursos
aplicações recursos recursos recursos
Tipo de Partilhado Partilhado Dedicado3 Dedicado3 Dedicado3 Dedicado3

instância
computacional
Escala para 1 partilhado 1 partilhado 3dedicado 3 10dedicado s 3 30dedicado s 3 100dedicado s 4

fora
(instâncias
máximas)
Armazenamen 1 GB5 1 GB5 10 GB5 50 GB5 250 GB5 1 TB5

to5
Para mais de A quota de
250 GB, armazenamen
submeta um to disponível é
pedido de de 999 GB.
apoio.
Tempo de 3 minutos 3 minutos Ilimitado, Ilimitado, Ilimitado, Ilimitado,

CPU (5 pague a taxas pague a taxas pague a taxas pague a taxas
minutos)6 padrão padrão padrão padrão
Hora do CPU 60 minutos 240 minutos Ilimitado, Ilimitado, Ilimitado, Ilimitado,

(dia)6 pague a taxas pague a taxas pague a taxas pague a taxas
padrão padrão padrão padrão
Memória (1 1.024 MB por 1.024 MB por N/D N/D N/D N/D

hora) plano de app
serviço de
aplicações
Largura de 165 MB Tarifas Tarifas Tarifas Tarifas Tarifas

banda ilimitadas de ilimitadas de ilimitadas de ilimitadas de ilimitadas de
transferência transferência transferência transferência transferência
de dados de dados de dados de dados de dados
aplicam-se aplicam-se aplicam-se aplicam-se aplicam-se
Arquitetura da 32 bits 32 bits 32-bit/64-bit 32-bit/64-bit 32-bit/64-bit 32-bit/64-bit

aplicação
Tomadas web 5 35 350 Ilimitado Ilimitado Ilimitado

por instância7
Ligações IP 600 600 Depende do Depende do Depende do 16 000

tamanho da tamanho da tamanho da
instância8 instância8 instância8
Conexões de 1 1 1 5 5 5
debugger
simultâneas
por aplicação
Certificados Não Não 10 10 10 10

de serviço de suportado suportado
aplicações por
subscrição9
Domínios 0 (apenas 500 500 500 500 500

personalizado subdomínio
s por app azurewebsites.
net)
Suporte sSL Não Não Ligações SNI Conexões Conexões Conexões

de domínio suportado, suportado, SSL ilimitadas Ilimitadas SNI Ilimitadas SNI Ilimitadas SNI
personalizado certificado certificado SSL e 1 IP SSL SSL e 1 IP SSL SSL e 1 IP SSL
wildcard para wildcard para incluídas incluídas incluídas
*.azurewebsite *.azurewebsite
s.net s.net
disponível por disponível por
padrão padrão
Conexões 5 25 200 200

híbridas por
plano
Equilibrador X X X X X10
de carga
integrado
Sempre ligado X X X X
Backups Backups Backups Backups

programados programados programados programados
a cada 2 a cada hora, a cada hora,
horas, um um máximo um máximo
máximo de 12 de 50 backups de 50 backups
backups por por dia por dia
dia (manual + (manual + (manual +
agendado) agendado) agendado)
Dimensionam X X X
ento
Automático
WebJobs11 X X X X X X
Monitorização X X X X
de ponto final
Slots de 5 20 20
encenação por
app
SLA 99,95% 99,95% 99,95% 99,95%
1 Aplicações e quotas de armazenamento são de acordo com o plano de Serviço de Aplicações, a menos que se
note o contrário.
2 O número real de aplicações que pode alojar nestas máquinas depende da atividade das aplicações, do tamanho
das instâncias da máquina e da utilização correspondente de recursos.
3 Casos dedicados podem ter tamanhos diferentes. Para mais informações, consulte os preços do Serviço de
Aplicações.
4 Mais são permitidos mediante pedido.
5 O limite de armazenamento é o tamanho total do conteúdo em todas as aplicações no mesmo plano de serviço
app. O tamanho total do conteúdo de todas as aplicações em todos os planos de serviço seletiva de um único
grupo de recursos e região não pode exceder 500GB.
6 Estes recursos são limitados por recursos físicos nas instâncias dedicadas (a dimensão da instância e o número de
instâncias).
7 Se escalar uma aplicação no nível Básico para dois casos, tem 350 ligações simultâneas para cada uma das duas
instâncias. Para o nível Standard e acima, não existem limites teóricos para as tomadas web, mas outros fatores
podem limitar o número de tomadas web. Por exemplo, os pedidos máximos maxConcurrentRequestsPerCpu
simultâneos permitidos (definidos por ) são: 7.500 por pequeno VM, 15.000 por VM médio (7.500 x 2 núcleos) e
75.000 por VM grande (18.750 x 4 núcleos).
8 As ligações IP máximas são por exemplo e dependem do tamanho da instância: 1.920 por instância B1/S1/P1V2,
3.968 por instância B2/S2/P2V2, 8.064 por instância B3/S3/P3V2.

9 O limite de quota de certificado de serviço de aplicação por subscrição pode ser aumentado através de um
pedido de suporte para um limite máximo de 200.

10 Serviço de aplicações SKUs isolados podem ser equilibrados internamente (ILB) com Azure Load Balancer, por
isso não há conectividade pública da internet. Como resultado, algumas funcionalidades de um Serviço de
Aplicações Isoladas ILB devem ser utilizadas a partir de máquinas que tenham acesso direto ao ponto final da rede
ILB.
11 Execute executáveis e/ou scripts personalizados a pedido, numa programação, ou continuamente como uma
tarefa de fundo dentro da sua instância de Serviço de Aplicações. Always On é necessário para execução contínua
de WebJobs. Não existe um limite predefinido para o número de WebJobs que podem ser executados numa
instância do Serviço de Aplicações. Existem limites práticos que dependem do que o código de aplicação está a
tentar fazer.
Limites de automação
Automatização de processos
REC URSO L IM IT E N OTA S
Número máximo de novos postos de 100 Quando este limite é atingido, os

trabalho que podem ser submetidos a pedidos subsequentes para criar um
cada 30 segundos por conta Azure emprego falham. O cliente recebe uma
Automation (empregos não resposta de erro.
programados)
Número máximo de postos de trabalho 200 Quando este limite é atingido, os

correntes simultâneos no mesmo pedidos subsequentes para criar um
período de tempo por conta emprego falham. O cliente recebe uma
automation (empregos não resposta de erro.
programados)
Tamanho máximo de armazenamento 10 GB (aproximadamente 4 milhões de Quando este limite é atingido, os

de metadados de trabalho para um empregos) pedidos subsequentes para criar um
período de 30 dias de rolamento emprego falham.
Limite máximo de fluxo de emprego 1 MB Um único fluxo não pode ser maior que
1 MB.
Número máximo de módulos que 5

podem ser importados a cada 30
segundos por conta de Automação
Tamanho máximo de um módulo 100 MB
Tempo de execução de emprego, nível 500 minutos por subscrição por mês
livre
Quantidade máxima de espaço em 1 GB Aplica-se apenas às caixas de areia

disco permitido por caixa de areia1 Azure.
Quantidade máxima de memória dada a 400 MB Aplica-se apenas às caixas de areia

uma caixa de areia1 Azure.
Número máximo de tomadas de rede 1,000 Aplica-se apenas às caixas de areia

permitidas por caixa de areia1 Azure.
Tempo máximo de execução permitido 3 horas Aplica-se apenas às caixas de areia

por livrode co rridas 1 Azure.
Número máximo de contas de Sem limite

Automação numa subscrição
Número máximo de Grupos de 4000

Trabalhadores Híbridos por Conta de
Automação
Número máximo de empregos 50

simultâneos que podem ser executados
num único Trabalhador híbrido
Tamanho máximo do parâmetro de 512 quilobits

trabalho do livro de corridas
Parâmetros máximos de escadirinco 50 Se atingir o limite de 50 parâmetros,

pode passar uma corda JSON ou XML a
um parâmetro e analisá-la com o livro
de execução.
Tamanho máximo da carga útil do 512 quilobits

webhook
Máximo sem dias que os dados do 30 dias

trabalho são retidos
Tamanho máximo do estado do fluxo de 5 MB Aplica-se aos livros de fluxo de trabalho

trabalho PowerShell powerShell ao checkpoint do fluxo de
trabalho.
1 Uma caixa de areia é umambiente partilhado que pode ser usado por vários trabalhos. Os empregos que
utilizam a mesma caixa de areia estão ligados às limitações de recursos da caixa de areia.
Controlo de Alterações e Inventário
A tabela seguinte mostra os limites de item rastreados por máquina para o rastreio de alterações.
Ficheiro 500
Registo 250
Software windows 250 Não inclui atualizações de software.
Pacotes Linux 1,250
Serviços 250
Daemon 250
Gestão de Atualizações
O quadro seguinte mostra os limites para a Gestão de Atualizações.
Número de máquinas por 1000

implementação de atualização
Cache Azure para os limites de Redis

REC URSO L IM IT E
Tamanho da cache 1.2 TB
Bases de Dados 64
Clientes máximos ligados 40.000
Azure Cache para réplicas Redis, para alta disponibilidade 1
Fragmentos em uma cache premium com agrupamento 10
O Azure Cache para os limites e tamanhos do Redis é diferente para cada nível de preços. Para ver os níveis de
preços e os seus tamanhos associados, consulte o Azure Cache para os preços redis.
Para obter mais informações sobre o Azure Cache para os limites de configuração do Redis, consulte a
configuração do servidor Predefinido Redis.
Uma vez que a configuração e gestão do Azure Cache para os casos Redis é feita pela Microsoft, nem todos os
comandos Redis são suportados em Azure Cache para Redis. Para mais informações, consulte comandos Redis não
suportados em Azure Cache for Redis.
Limites dos Serviços Azure Cloud

REC URSO L IM IT E
Funções web ou trabalhador por implantação1 25

REC URSO L IM IT E
Pontos finais de entrada por exemplo por implantação 25
Pontos finais de entrada por implantação 25
Pontos finais internos por implantação 25
Certificados de serviço hospedados por implantação 199
1 Cada Serviço Azure Cloud com funções web ou operárias pode ter duas implementações, uma para produção e
outra para encenação. Este limite refere-se ao número de funções distintas, isto é, configuração. Este limite não se
refere ao número de instâncias por função, isto é, escalando.
Limites de Pesquisa Cognitiva Azure

Os níveis de preços determinam a capacidade e os limites do seu serviço de pesquisa. Os níveis incluem:
O serviço gratuito multi-inquilino, partilhado com outros subscritores do Azure, destina-se a avaliação e
pequenos projetos de desenvolvimento.
A Basic fornece recursos computamento dedicados para cargas de trabalho de produção em menor escala,
com até três réplicas para cargas de trabalho de consulta altamente disponíveis.
Standard , que inclui S1, S2, S3 e S3 High Density, destina-se a maiores cargas de trabalho de produção.
Existem vários níveis dentro do nível Standard para que possa escolher uma configuração de recurso que
melhor corresponda ao seu perfil de carga de trabalho.
Limites por subscrição
Pode criar vários serviços dentro de uma subscrição. Cada um pode ser provisionado a um nível específico. Está
limitado apenas pelo número de serviços permitidos em cada nível. Por exemplo, pode criar até 12 serviços no
nível Básico e outros 12 serviços no nível S1 dentro da mesma subscrição. Para mais informações sobre os níveis,
consulte Escolha um SKU ou um nível para Pesquisa Cognitiva Azure.
Os limites máximos de serviço podem ser aumentados mediante solicitação. Se precisar de mais serviços dentro
da mesma subscrição, contacte o Suporte Azure.
REC URSO GRÁT IS 1 B Á SIC O S1 S2 S3 S3 H D L1 L2
Serviços 1 16 16 8 6 6 6 6
máximos
Escala N/D 3 SU 36 SU 36 SU 36 SU 36 SU 36 SU 36 SU
máxima
em
unidades
de busca
(SU)2
1 O Free baseia-se em recursos partilhados, não dedicados. A escala não é apoiada em recursos partilhados.
2 As unidades de pesquisa são unidades de faturação, atribuídas como uma réplica ou uma divisória. Precisa de
ambos os recursos para operações de armazenamento, indexação e consulta. Para saber mais sobre as
computações da SU, consulte os níveis de recursos de escala para consultas e cargas de trabalho indexadas.
Limites por ser viço de pesquisa
Um serviço de pesquisa é limitado pelo espaço do disco ou por um limite rígido no número máximo de índices ou
indexadores, o que vier em primeiro lugar. Os seguintes documentos de tabela limitam-se ao armazenamento. Para
obter limites máximos de objetos, consulte Limites por recurso.
REC URSO GRAT UITO B Á SIC O 1 S1 S2 S3 S3 H D L1 L2
Acordo de Não Sim Sim Sim Sim Sim Sim Sim

nível de
serviço
(SLA)2
Armazena 50 MB 2 GB 25 GB 100 GB 200 GB 200 GB 1 TB 2 TB

mento
por
partição
Partições N/D 1 12 12 12 3 12 12
por
serviço
Tamanho N/D 2 GB 25 GB 100 GB 200 GB 200 GB 1 TB 2 TB

da
partição
Réplicas N/D 3 12 12 12 12 12 12
1 O básico temuma divisória fixa. Unidades de pesquisa adicionais podem ser usadas para adicionar réplicas para
volumes de consulta maiores.
2 Os contratos de nível de serviço estão em vigor para serviços faturados em recursos dedicados. Serviços
gratuitos e funcionalidades de pré-visualização não têm SLA. Para serviços de faturação, os SLAs efetuam efeitos
quando prevê redundância suficiente para o seu serviço. São necessárias duas ou mais réplicas para consulta (ler)
SLAs. São necessárias três ou mais réplicas para consulta e indexação (read-write) SLAs. O número de divisórias
não é uma consideração da SLA.
Para saber mais sobre limites a um nível mais granular, como tamanho de documento, consultas por segundo,
chaves, pedidos e respostas, consulte os limites de serviço na Pesquisa Cognitiva Azure.
Limites dos Serviços Cognitivos Azure

Os seguintes limites destinam-se ao número de recursos dos Serviços Cognitivos por subscrição do Azure. Cada
um dos Serviços Cognitivos pode ter limitações adicionais, para mais informações ver Serviços Cognitivos Azure.
T IP O L IM IT E EXEM P LO
Uma mistura de recursos de Serviços Máximo de 200 recursos totais dos 100 recursos de Visão Computacional
Cognitivos Serviços Cognitivos. em West US 2, 50 Recursos do Speech
Service no Oeste dos EUA e 50 recursos
de Análise de Texto no Leste dos EUA.
Um único tipo de recursos dos Serviços Máximo de 100 recursos por região, 100 recursos de Visão Computacional
Cognitivos. com um máximo de 200 recursos totais em West US 2 e 100 recursos de Visão
dos Serviços Cognitivos. Computacional no Leste dos EUA.
Limites de DB de Azure Cosmos

Para os limites de DB de Azure Cosmos, consulte Limits in Azure Cosmos DB.
Limites do Explorador de Dados Azure

A tabela que se segue descreve os limites máximos para os clusters do Azure Data Explorer.
REC URSO L IM IT E
Aglomerados por região por subscrição 20
Instâncias por cluster 1000
Número de bases de dados num cluster 10,000
Número de configurações de bases de dados anexadas num 70

cluster
O quadro seguinte descreve os limites das operações de gestão realizadas nos clusters do Azure Data Explorer.
Â M B ITO O P ERA Ç Ã O L IM IT E
Cluster ler (por exemplo, obter um cluster) 500 por 5 minutos
Cluster escrever (por exemplo, criar uma base 1000 por hora
de dados)

Para a base de dados Azure para os limites do MySQL, consulte as limitações na Base de Dados Azure para o
MySQL.

Para a base de dados Azure para limites pós-SQL, consulte limitações na Base de Dados Azure para PostgreSQL.
Limites de funções Azure

P L A N O DE SERVIÇ O DE
REC URSO P L A N O DE C O N SUM O P L A N O P REM IUM A P L IC A Ç Õ ES 1
Aumentar horizontalmente Orientada por eventos Orientada por eventos Manual/escala automática
Casos max 200 100 10-20
Duração do tempo de 5 30 302

paragem por defeito (min)
Duração máxima do tempo 10 ilimitada8 semlimites 3

limite (min)
Ligações de saída max (por 600 ativos (1200 no total) sem limites sem limites
exemplo)
P L A N O DE SERVIÇ O DE
REC URSO P L A N O DE C O N SUM O P L A N O P REM IUM A P L IC A Ç Õ ES
Tamanho máximo do pedido 100 100 100

(MB)4
Comprimento de corda de 4096 4096 4096

consulta máxima4
Comprimento de URL de 8192 8192 8192

pedido máximo4
ACU por instância 100 210-840 100-840
Memória máxima (GB por 1.5 3.5-14 1.75-14

exemplo)
Aplicativos de função por 100 100 ilimitada5

plano
Planos do Serviço de 100 por região 100 por grupo de recursos 100 por grupo de recursos
Aplicações
Armazenamento6 1 GB 250 GB 50-1000 GB
Domínios personalizados por 5007 500 500

app
Suporte sSL de domínio Conexão SNI SSL não Conexões SNI SSL e 1 IP SSL Conexões SNI SSL e 1 IP SSL
personalizado limitada incluída incluídas incluídas
1 Para limites específicos para as várias opções do plano de app service, consulte os limites do plano do Serviço de
Aplicações.
2 Por predefinição, o tempo limite para as Funções 1.x tempo de execução num plano de Serviço de Aplicações não
está limitado.
3 Requer que o plano de serviço de aplicações seja definido para sempre ligado. Pague a preçospadrão.
4 Estes limites estão fixados no hospedeiro.
5 O número real de aplicações de função que pode acolher depende da atividade das aplicações, do tamanho das
instâncias da máquina e da utilização de recursos correspondentes.

6 O limite de armazenamento é o tamanho total do conteúdo em armazenamento temporário em todas as
aplicações no mesmo plano de Serviço de Aplicações. O plano de consumo utiliza ficheiros Azure para
armazenamento temporário.
7 Quando a sua aplicação de funções estiver hospedada num plano de consumo,apenas a opção CNAME é
suportada. Para aplicações de função num plano Premium ou num plano de Serviço de Aplicações,pode mapear
um domínio personalizado usando um CNAME ou um registo A.
8 Garantido até 60 minutos.
Limites de serviço Azure Kubernetes

REC URSO L IM IT E
Clusters máximos por subscrição 100

REC URSO L IM IT E
Nómáximo por cluster com conjuntos de disponibilidade de 100

máquinas virtuais e Balancer de carga básica SKU
Nómáximo por cluster com conjuntos de escala de máquina 1000 (100 nós por piscina de nós)
virtual e Balancer de carga padrão SKU
Cápsulas máximas por nó: Networking básico com Kubenet 110
Cápsulas máximas por nó: Rede avançada com interface de Implementação da CLI do Azure: 301
rede de contentores Azure Modelo de Gestor de Recursos Azure: 301
Implementação do portal: 30
1 Quando implementa um cluster de Serviço Azure Kubernetes (AKS) com o Modelo Azure CLI ou um Gestor de
Recursos, este valor é configurável até 250 cápsulas por nó. Não é possível configurar cápsulas máximas por nó
depois de já ter implantado um cluster AKS, ou se implementar um cluster utilizando o portal Azure.
Limites de aprendizagem automática Azure

Os valores mais recentes para as quotas de cálculo de aprendizagem automática Azure podem ser encontrados na
página de quotas de aprendizagem automática Azure
Limites do Azure Maps

A tabela que se segue mostra o limite de utilização para o nível de preços Azure Maps S0. O limite de utilização
depende do nível de preços.
REC URSO L IM IT E DE N ÍVEL DE P REÇ O S S0
Taxa máxima de pedidos por subscrição 50 pedidos por segundo
O quadro seguinte mostra o limite acumulado de tamanho de dados para contas Do Azure Maps numa subscrição
do Azure. O serviço de dados Do Azure Maps está disponível apenas no nível de preços S1.
REC URSO L IM IT E
Armazenamento máximo por subscrição do Azure 1 GB
Tamanho máximo por upload de ficheiros 100 MB
Para obter mais informações sobre os níveis de preços do Azure Maps, consulte os preços do Azure Maps.
Limites do Monitor Azure

Alertas
REC URSO L IM IT E P REDEF IN IDO L IM IT E M Á XIM O
Alertas métricos (clássico) 100 regras de alerta ativo por Apoio de chamada.
subscrição.
Alertas de métricas 2.000 regras de alerta ativo por Apoio de chamada.

subscrição em nuvens públicas azure,
Azure China 21Vianet e Azure
Government. Se estiver a atingir este
limite, explore se pode usar alertas
multi-recursos do mesmo tipo
Alertas do registo de atividades 100 regras de alerta ativo por O mesmo que o padrão.
subscrição.
Alertas de registo 512 regras de alerta ativo por Apoio de chamada.

subscrição. 200 regras de alerta ativo
por recurso.
Grupos de ação 2.000 grupos de ação por subscrição. Apoio de chamada.
Definições de escala automática 100 por região por subscrição. O mesmo que o padrão.
Perfis de escala automática 20 perfis por definição de escala O mesmo que o padrão.
automática.
Grupos de ação
Impulso da aplicação Azure 10 ações de aplicações Azure por grupo Apoio de chamada.
de ação.
Email 1.000 ações de e-mail num grupo de Apoio de chamada.

ação.
Não mais de 100 e-mails numa hora.
Consulte também a taxa que limita a
informação.
ITSM 10 ações da ITSM num grupo de ação. Apoio de chamada.
Aplicação lógica 10 ações de aplicativos lógicos num Apoio de chamada.

grupo de ação.
Runbook 10 ações de livro num grupo de ação. Apoio de chamada.
SMS 10 ações sms num grupo de ação. Apoio de chamada.

Não mais do que 1 mensagem SMS a
cada 5 minutos.
informação.
Voz 10 ações de voz num grupo de ação. Apoio de chamada.

Não mais do que uma chamada de voz
a cada 5 minutos.
informação.
Webhook 10 ações de webhook num grupo de Apoio de chamada.

ação. O número máximo de chamadas
webhook é de 1500 por minuto por
subscrição. Outros limites estão
disponíveis em informações específicas
para a ação.
Consultas de registo e linguagem

Limites gerais de consulta
L IM IT E DESC RIÇ Ã O
Linguagem da consulta O Azure Monitor usa a mesma linguagem de consulta Kusto

que o Azure Data Explorer. Consulte as diferenças linguísticas
de consulta de registo do Azure Monitor para elementos
linguísticos KQL não suportados no Monitor Azure.
Regiões do Azure As consultas de registo podem experimentar sobrecargas

excessivas quando os dados abrangem espaços de trabalho
do Log Analytics em várias regiões do Azure. Consulte os
limites de consulta para mais detalhes.
Consultas de recursos cruzados Número máximo de recursos de Application Insights e espaços

de trabalho log Analytics numa única consulta limitada a 100.
A consulta de recursos cruzados não é suportada no View
Designer.
A consulta de recursos cruzados em alertas de registo é
suportada na nova API agendada.
Consulte os limites de consulta de recursos cruzados para
obter detalhes.
Estrangulamento da consulta do utilizador

O Monitor Azure tem vários limites de estrangulamento para proteger contra os utilizadores que enviam um
número excessivo de consultas. Tal comportamento pode potencialmente sobrecarregar os recursos de backend do
sistema e comprometer a capacidade de resposta do serviço. Os seguintes limites destinam-se a proteger os
clientes de interrupções e a garantir um nível de serviço consistente. O estrangulamento e os limites do utilizador
são concebidos para impactar apenas um cenário de utilização extremo e não devem ser relevantes para a
utilização típica.
M EDIR L IM IT E P O R UT IL IZ A DO R DESC RIÇ Ã O
Consultas simultâneas 5 Se já existem 5 consultas em execução

para o utilizador, quaisquer novas
consultas são colocadas numa fila de
condivisões por utilizador. Quando uma
das consultas de corrida terminar, a
próxima consulta será retirada da fila e
iniciada. Isto não inclui consultas de
regras de alerta.
Tempo na fila da moeda 2,5 minutos Se uma consulta se sentar na fila por
mais de 2,5 minutos sem ser iniciada,
será terminada com uma resposta de
erro HTTP com o código 429.
M EDIR L IM IT E P O R UT IL IZ A DO R DESC RIÇ Ã O
Consultas totais na fila da moeda 40 Uma vez que o número de consultas na

fila atinja 40, quaisquer consultas
adicionais serão rejeitadas com um
código de erro HTTP 429. Este número
é além das 5 consultas que podem ser
em funcionamento simultaneamente.
Taxa de consulta 200 consultas por 30 segundos Esta é a taxa global que as consultas
podem ser submetidas por um único
utilizador a todos os espaços de
trabalho. Este limite aplica-se a consultas
programáticas ou consultas iniciadas
por peças de visualização, como os
dashboards Azure e a página de resumo
do espaço de trabalho Log Analytics.
Otimize as suas consultas conforme descrito nas consultas de registo otimizadas no Monitor Azure.
Dashboards e livros de trabalho podem conter múltiplas consultas numa única vista que geram uma explosão
de consultas sempre que carregam ou atualização. Considere dividi-los em várias visões que carregam a
pedido.
No Power BI, considere extrair apenas resultados agregados em vez de troncos brutos.
Áreas de trabalho do Log Analytics
Volume e retenção de recolha de dados
ESC A L Ã O L IM IT E P O R DIA RET EN Ç Ã O DE DA DO S C O M EN TÁ RIO
Nível de preços atual por GB Sem limite 30 - 730 dias A retenção de dados para
(introduzido abril de 2018) além dos 31 dias está
disponível para encargos
adicionais. Saiba mais sobre
os preços do Monitor Azure.
Níveis livres legados 500 MB 7 dias Quando o seu espaço de

(introduzido abril de 2016) trabalho atinge o limite de
500 MB por dia, a ingestão
de dados para e retoma no
início do dia seguinte. Os
dias são baseados no fuso
horário UTC. Note que os
dados recolhidos pelo Azure
Security Center não estão
incluídos neste limite de 500
MB por dia e continuarão a
ser recolhidos acima deste
limite.
Legado Autónomo por nível Sem limite 30 a 730 dias A retenção de dados para
GB além dos 31 dias está
(introduzido abril de 2016) disponível para encargos
ESC A L Ã O L IM IT E P O R DIA RET EN Ç Ã O DE DA DO S C O M EN TÁ RIO
Legado por nó (OMS) Sem limite 30 a 730 dias A retenção de dados para
(introduzido abril de 2016) além dos 31 dias está
disponível para encargos
Nível Padrão Legado Sem limite 30 dias A retenção não pode ser
ajustada
Nível Legacy Premium Sem limite 365 dias A retenção não pode ser
ajustada
Número de espaços de trabalho por subscrição.
ESC A L Ã O DE P REÇ O L IM IT E DE ESPA Ç O DE T RA B A L H O C O M EN TÁ RIO S
Escalão gratuito 10 Este limite não pode ser aumentado.
Todos os outros níveis Sem limite Está limitado pelo número de recursos
dentro de um grupo de recursos e pelo
número de grupos de recursos por
subscrição.
Por tal do Azure
C AT EGO RIA L IM IT E C O M EN TÁ RIO S
Registos máximos devolvidos por uma 10,000 Reduza os resultados utilizando o

consulta de registo âmbito de consulta, o intervalo de
tempo e os filtros na consulta.
API de colecionador de dados
Tamanho máximo para um único poste 30 MB Divida volumes maiores em vários

postes.
Tamanho máximo para valores de 32 KB Os campos com mais de 32 KB são

campo truncados.
API de Pesquisa
Registos máximos devolvidos numa 500 000

única consulta
Tamanho máximo dos dados devolvidos 64.000.000 bytes (~61 MiB)
Tempo máximo de consulta 10 minutos Consulte os Timeouts para obter mais

detalhes.
Taxa máxima de pedido 200 pedidos por 30 segundos por Consulte os limites de tarifa ção para
utilizador aAD ou endereço IP do cliente mais detalhes.
Limites gerais do espaço de trabalho
Colunas máximas numa tabela 500
Caracteres máximos para o nome da 500

coluna
Exportação de dados Não disponível atualmente Utilize a Função Azure ou a App Lógica
para agregar e exportar dados.
Taxa de volume de ingestão de dados

O Azure Monitor é um serviço de dados de alta escala que serve milhares de clientes que enviam terabytes de
dados todos os meses a um ritmo crescente. O limite de taxa de volume de ingestão padrão para os dados
enviados a partir de recursos Do Azure utilizando configurações de diagnóstico é de aproximadamente 6 GB/min
por espaço de trabalho. Este é um valor aproximado, uma vez que o tamanho real pode variar entre os tipos de
dados dependendo do comprimento do registo e da sua relação de compressão. Este limite não se aplica aos
dados enviados por agentes ou pela API do Coletorde Dados .
Se enviar dados a uma taxa mais elevada para um único espaço de trabalho, alguns dados são retirados e um
evento é enviado para a tabela Operação no seu espaço de trabalho a cada 6 horas enquanto o limiar continua a
ser ultrapassado. Se o seu volume de ingestão continuar a exceder o limite de taxa ou se estiver à
LAIngestionRate@microsoft.com espera de o atingir em breve, poderá solicitar um aumento para o seu espaço de
trabalho enviando um e-mail para ou abrindo um pedido de apoio.
Para ser notificado sobre tal evento no seu espaço de trabalho, crie uma regra de alerta de registo utilizando a
seguinte consulta com base lógica de alerta no número de resultados do que zero.
Operation
|where OperationCategory == "Ingestion"
|where Detail startswith "The rate of data crossed the threshold"
NOTE
Dependendo do tempo que tem usado o Log Analytics, poderá ter acesso a níveis de preços antigos. Saiba mais sobre os
níveis de preços do legado Log Analytics.
Application Insights
Existem alguns limites para o número de métricas e eventos por aplicação, isto é, por chave de instrumentação. Os
limites dependem do plano de preços que escolher.
REC URSO L IM IT E N OTA

Total de dados por dia 100 GB Pode reduzir os dados ao definir um

limite. Se precisar de mais dados, pode
aumentar o limite no portal, até 1.000
GB. Para capacidades superiores a 1.000
AIDataCap@microsoft.comGB, envie e-
mail para .
Limitação 32.000 eventos/segundo O limite é mediso ao longo de um

minuto.
Retenção de dados 90 dias Este recurso é para Pesquisa, Análise e

Explorador de métricas.
Teste de disponibilidade de vários 90 dias Este recurso fornece resultados

passos com retenção de resultados detalhados de cada passo.
detalhados
Tamanho máximo do evento 64.000.000 bytes
Comprimento do nome da propriedade 150 Ver tipo de schemas.

e da métrica
Comprimento da cadeia de valor da 8,192 Ver tipo de schemas.

propriedade
Comprimento da mensagem de exceção 32,768 Ver tipo de schemas.

e de rastreio
Testes de disponibilidade com contagem 100

por aplicação
Retenção de dados do profiler 5 dias
Dados do perfil enviados por dia 10 GB
Para mais informações, consulte About pricing and quotas in Application Insights (Acerca de preços e quotas no
Application Insights).
Limites da Política Azure

Há uma contagem máxima para cada tipo de objeto para Azure Policy. Uma entrada de Âmbito significa a
subscrição ou o grupo de gestão.
O N DE O Q UÊ C O N TA GEM M Á XIM A
Âmbito Definições de política 500
Âmbito Definições de iniciativa 100
Inquilino Definições de iniciativa 2.500
Âmbito Atribuições de política ou iniciativa 100

O N DE O Q UÊ C O N TA GEM M Á XIM A
Definição de política Parâmetros 20
Definição de iniciativa Políticas 100
Definição de iniciativa Parâmetros 100
Atribuições de política ou iniciativa Exclusões (notScopes) 400
Regra política Condições aninhadas 512
Tarefa de reparação Recursos 500
Limites de serviço Azure SignalR

Unidades de serviço de sinalização 1 1

Azure por exemplo para o nível gratuito
Unidades de serviço de sinalização 100 100

Azure por exemplo para o nível
Standard
Unidades de serviço de Sinalização 5 5

Azure por subscrição por região para
free tier
Total da unidade de serviço de 150 Ilimitado

sinalização Azure conta por subscrição
por região
Ligações por unidade por dia para o 20 20

free tier
Ligações por unidade por dia para o 1,000 1,000

nível Standard
Mensagens incluídas por unidade por 20 000 20 000

dia para o free tier
Mensagens adicionais por unidade por 0 0

dia para o free tier
Mensagens incluídas por unidade por 1 000 000 1 000 000

dia para o nível Standard
Mensagens adicionais por unidade por Ilimitado Ilimitado

dia para o nível Standard
Para solicitar uma atualização dos limites predefinidos da sua subscrição, abra um bilhete de suporte.
Limites de backup
Para um resumo das definições e limitações de suporte de backup Azure, consulte Matrizesde Suporte de Backup
Azure .
Limites de lote
Contas Azure Batch por região por 1-3 50

subscrição
Núcleos dedicados por conta Batch 90-900 Contactar o suporte
Núcleos de baixa prioridade por conta 10-100 Contactar o suporte

batch
Empregos ativos e horários de 100-300 1.0001

trabalho por conta batch (os
empregosconcluídos não têm limite)
Conjuntos por conta do Batch 20-100 5001
1 Para solicitar um aumento para além deste limite, contacte o Suporte Azure.
IMPORTANT
Estamos a mudar a forma como solicita e gere quota dedicada. O total de vCPUs dedicados é o valor atualmente aplicado,
mas em breve iremos impor quotas dedicadas por série VM. A quota de baixa prioridade continuará a ser aplicada com base
no limite total; não será aplicada pela série VM.
NOTE
Os limites predefinidos variam consoante o tipo de subscrição que utiliza para criar uma conta Batch. As quotas de núcleos
apresentadas são para contas Batch no modo de serviço Batch. Veja as quotas na sua conta Batch.
IMPORTANT
Para nos ajudar a gerir melhor a capacidade durante a pandemia global de saúde, as quotas fundamentais padrão para novas
contas de Lote em algumas regiões e para alguns tipos de subscrição foram reduzidas do intervalo de valores acima, em
alguns casos para núcleos zero. Quando criar uma nova conta Batch, verifique a sua quota principal e solicite um aumento de
quota de base,se necessário.
Limites clássicos do modelo de implantação

Se utilizar o modelo de implementação clássico em vez do modelo de implementação do Gestor de Recursos
Azure, aplicam-se os seguintes limites.
vCPUs por subscrição1 20 10,000
Coadministradores por subscrição 200 200

Contas de armazenamento por 100 100

subscrição2
Serviços cloud por subscrição 20 200
Redes locais por subscrição 10 500
Servidores DNS por subscrição 9 100
IPs reservados por subscrição 20 100
Grupos de afinidade por subscrição 256 256
Comprimento do nome da subscrição 64 64

(caracteres)
1 Casos extra pequenos contam como um vCPU em direção ao limite vCPU, apesar de utilizar um núcleo de CPU
parcial.
2 O limite da conta de armazenamento inclui contas de armazenamento Standard e Premium.
Limites de casos de contentores

REC URSO L IM IT E
Grupos de contentores padrão sku por região por subscrição 1001
Grupos de contentores sku dedicados por região por 01

subscrição
Número de contentores por grupo de contentores 60
Número de volumes por grupo de contentores 20
Portas por IP 5
Tamanho do registo da instância do recipiente - instância de 4 MB

execução
Tamanho do registo da instância do recipiente - instância 16 KB ou 1.000 linhas

parada
Contentor cria por hora 3001
Contentor cria por 5 minutos 1001
Contentor elimina por hora 3001
Contentor elimina por 5 minutos 1001
1 Para solicitar um aumento de limite, crie um pedido de apoio azure.

Limites do registo de contentores
O quadro seguinte detalha as características e limites dos níveisde serviço Básico, Standard e Premium.
REC URSO B Á SIC O STA N DA RD P REM IUM
Armazenamento1 10 GiB 100 GiB 500 GiB
Tamanho máximo da camada 200 GiB 200 GiB 200 GiB

de imagem
ReadOps por minuto2, 3 1,000 3.000 10,000
WriteOps por minuto2, 4 100 500 2.000
Baixar largura de banda 30 60 100

MBps2
Carregar largura de banda 10 20 50

MBps2
Webhooks 2 10 500
Georreplicação N/D N/D Apoiado
Confiança de conteúdo N/D N/D Apoiado
Ligação privada com pontos N/D N/D Apoiado

finais privados
Acesso vNet endpoint de N/D N/D previsualizar

serviço
Chaves geridas pelo cliente N/D N/D Apoiado
Permissões com âmbito de N/D N/D previsualizar

repositório
•Fichas N/D N/D 20 000
•Mapas de âmbito N/D N/D 20 000
•Repositórios por mapa de N/D N/D 500

âmbito
1 Os limites de armazenamento especificados são a quantidade de armazenamento incluído para cada nível. É-lhe
cobrada uma taxa diária adicional por GiB para armazenamento de imagem acima destes limites. Para obter
informações sobre tarifas, consulte os preços do Registo de Contentores de Azure.
2ReadOps, WriteOpse Largura de Banda são estimativas mínimas. O Registo de Contentores Azure esforça-se por
melhorar o desempenho conforme o uso requer.

3 Um puxão de estiva traduz-se em múltiplas operações de leitura baseadas no número de camadas na imagem,
mais a recuperação manifesta.
4 Um impulso de estivador traduz-se em múltiplas operações de escrita, com base no número de camadas que
devem ser empurradas. A docker push inclui ReadOps para recuperar um manifesto para uma imagem existente.
Limites da Rede de Entrega de Conteúdos

REC URSO L IM IT E
Perfis da Rede de Entrega de Conteúdos Azure 25
Pontos finais da Rede de Entrega de Conteúdos por perfil 25
Domínios personalizados por ponto final 25
Uma subscrição da Rede de Entrega de Conteúdos pode conter um ou mais perfis da Rede de Entrega de
Conteúdos. Um perfil da Rede de Entrega de Conteúdos pode conter um ou mais pontos finais da Rede de Entrega
de Conteúdos. É possível que pretenda utilizar vários perfis para organizar os pontos finais da sua Rede de Entrega
de Conteúdos por domínio de internet, aplicação web ou outros critérios.
Limites da Fábrica de Dados

A Azure Data Factory é um serviço multiarrendatário que tem os seguintes limites de incumprimento para garantir
que as subscrições dos clientes estão protegidas das cargas de trabalho uns dos outros. Para elevar os limites até
ao máximo para a sua subscrição, suporte de contato.
Versão 2
Fábricas de dados numa subscrição do 800 Suporte de contato.

Azure
Número total de entidades, tais como 5000 Suporte de contato.

oleodutos, conjuntos de dados,
gatilhos, serviços ligados e tempos de
execução de integração, dentro de uma
fábrica de dados
Total de núcleos de CPU para A 256 Suporte de contato.

Integração Azure-SSIS Runtimes sob
uma subscrição
Gasoduto simultâneo funciona por 10,000 Suporte de contato.

fábrica de dados que é partilhada entre
todos os oleodutos da fábrica
Atividade externa simultânea funciona 3.000 Suporte de contato.

por subscrição por região de Runtime
de Integração Azure
As atividades externas são geridas no tempo
de execução da integração, mas executam em
serviços ligados, incluindo Databricks,
procedimento armazenado, HDInsights, Web,
entre outros.
Atividade de Pipeline simultâneo 1000 Suporte de contato.

funciona por subscrição por região de
Runtime de Integração Azure
As atividades do pipeline executam no tempo
de execução da integração, incluindo Lookup,
GetMetadata e Delete.
Operações de autoria simultâneas por 200 Suporte de contato.

subscrição por região de Runtime de
Integração Azure
Incluindo a ligação de teste, a lista de pastas e
a lista de tabelas, os dados de pré-
visualização.
Unidades de Integração de Dados Grupo regional12 : 6000 Suporte de contato.

Simultâneos1 consumo por subscrição Grupo regional2 2 : 3000
por região de Execução de Integração Grupo regional 32 : 1500
Azure
Atividades máximas por gasoduto, que 40 40

incluem atividades interiores para
contentores
Número máximo de tempos de 100 Suporte de contato.

execução de integração ligados que
podem ser criados contra um único
tempo de execução de integração auto-
hospedado
Parâmetros máximos por gasoduto 50 50
Itens ForEach 100 000 100 000
Por cada paralelismo 20 50
Corridas máximas em fila por gasoduto 100 100
Caracteres por expressão 8,192 8,192
Intervalo mínimo do gatilho da janela 15 min 15 min

caindo
Prazo máximo para funcionações de 7 dias 7 dias

atividade sinuosidade
Bytes por objeto para objetos de 200 KB 200 KB

gasoduto3
Bytes por objeto para dataset e objetos 100 KB 2.000 KB

de serviço ligados3
Unidades de Integração de Dados1 por 256 Suporte de contato.

execução de atividade de cópia
Escrever chamadas API 1.200/h Suporte de contato.
Este limite é imposto pelo Gestor de

Recursos Azure, e não pela Azure Data
Factory.
Ler chamadas da API 12.500/h Suporte de contato.
Este limite é imposto pelo Gestor de

Recursos Azure, e não pela Azure Data
Factory.
Consultas de monitorização por minuto 1,000 Suporte de contato.
Operações DE CRUD da entidade por 50 Suporte de contato.

minuto
Tempo máximo da sessão de depuração 8 horas 8 horas

do fluxo de dados
Número simultâneo de fluxos de dados 50 Suporte de contato.

por fábrica
Número simultâneo de sessões de 3 3

depuração de fluxo de dados por
utilizador por fábrica
Limite de Fluxo de Dados Azure IR TTL 4 horas Suporte de contato.
1 A unidade de integração de dados (DIU) é utilizada numa operação de cópia cloud-to-cloud, aprenda mais com as
unidades de integração de dados (versão 2). Para obter informações sobre faturação, consulte os preços da Fábrica
de Dados azure.
2 O Tempo de Execução de Integração Azure está globalmente disponível para garantir a conformidade, eficiência e
redução dos custos de egress da rede.
GRUP O DA REGIÃ O REGIÕ ES
Grupo regional 1 Eua Central, Leste dos EUA, LESTE US2, Norte da Europa,
Europa Ocidental, Oeste dos EUA, Oeste DOS EUA
Grupo regional 2 Austrália Leste, Austrália Sudeste, Brasil Sul, Índia Central,
Japão Leste, Northcentral EUA, Southcentral EUA, Sudeste
Asiático, Oeste Dos EUA
Grupo 3 da região Canadá Central, Ásia Oriental, França Central, Coreia Central,
Reino Unido Sul
3 O pipeline, o conjunto de dados e os objetos de serviço ligados representam um agrupamento lógico da sua
carga de trabalho. Os limites para estes objetos não se relacionam com a quantidade de dados que pode mover e
processar com a Azure Data Factory. A Data Factory foi concebida para escalar para lidar com petabytes de dados.
Versão 1
Oleodutos dentro de uma fábrica de 2.500 Suporte de contato.

dados
Conjuntos de dados dentro de uma 5000 Suporte de contato.

fábrica de dados
Fatias simultâneas por conjunto de 10 10

dados
Bytes por objeto para objetos de 200 KB 200 KB

gasoduto1
Bytes por objeto para conjunto de 100 KB 2.000 KB

dados e objetos de serviço ligados1
Núcleos de cluster Azure HDInsight a 60 Suporte de contato.

pedido dentro de uma subscrição2
Unidades de movimento de dados em 32 Suporte de contato.

nuvem por atividade de cópia executar3
Contagem de retry para corridas de 1,000 MaxInt (32 bits)

atividade de gasoduto
1 O pipeline, o conjunto de dados e os objetos de serviço ligados representam um agrupamento lógico da sua
carga de trabalho. Os limites para estes objetos não se relacionam com a quantidade de dados que pode mover e
processar com a Azure Data Factory. A Data Factory foi concebida para escalar para lidar com petabytes de dados.
2 Os núcleos HDInsight a pedido são atribuídos fora da subscrição que contém a fábrica de dados. Como resultado,
o limite anterior é o limite central imposto pela Fábrica de Dados para os núcleos HDInsight a pedido. É diferente
do limite central que está associado à sua subscrição azure.
3 A unidade de movimento de dados em nuvem (DMU) para a versão 1 é utilizada numa operação de cópia cloud-
to-cloud, saiba mais com as unidades de movimento de dados cloud (versão 1). Para obter informações sobre
faturação, consulte os preços da Fábrica de Dados azure.
REC URSO L IM IT E IN F ERIO R PA DRÃ O L IM IT E M ÍN IM O
Intervalo de agendamento 15 minutos 15 minutos
Intervalo entre tentativas de repetição 1 segundo 1 segundo
Retry timeout value 1 segundo 1 segundo
Limites de chamada de serviço web

O Gestor de Recursos Azure tem limites para chamadas aPi. Pode fazer chamadas aPi a um ritmo dentro dos
limites da API do Gestorde Recursos Azure .
Limites do Data Lake Analytics

O Azure Data Lake Analytics facilita a complexa tarefa de gerir infraestruturas distribuídas e código complexo.
Disponibiliza recursos dinamicamente, e pode usá-lo para fazer análises em exabytes de dados. Quando o trabalho
termina, acaba automaticamente com os recursos. Só pagas pelo poder de processamento que foi usado. À medida
que aumenta ou diminui o tamanho dos dados armazenados ou a quantidade de cálculo utilizado, não tem de
reescrever o código. Para aumentar os limites predefinidos para a sua subscrição, contacte o suporte.
REC URSO L IM IT E C O M EN TÁ RIO S
Número máximo de postos de trabalho 20

simultâneos
Número máximo de unidades de análise 250 Utilize qualquer combinação de até um

(UA) por conta máximo de 250 Us em 20 postos de
trabalho. Para aumentar este limite,
contacte o Microsoft Support.
Tamanho máximo do script para 3 MB

submissão de emprego
Número máximo de contas data Lake 5 Para aumentar este limite, contacte o
Analytics por região por subscrição Microsoft Support.
Limites da Data Lake Store

Azure Data Lake Storage Gen1 é um repositório de hiperescala em toda a empresa para grandes cargas de
trabalho analíticas de dados. Pode utilizar data Lake Storage Gen1 para capturar dados de qualquer tamanho, tipo e
velocidade de ingestão num único local para análise operacional e exploratória. Não há limite para a quantidade de
dados que pode armazenar numa conta gen1 de armazenamento de data Lake.
Número máximo de contas Gen1 de 10 Para solicitar um aumento deste limite,

Armazenamento de Data Lake, por o suporte de contato.
subscrição, por região
Número máximo de ACLs de acesso, 32 Este é um limite difícil. Utilize grupos

por ficheiro ou pasta para gerir o acesso com menos
entradas.
Número máximo de ACLs predefinidos, 32 Este é um limite difícil. Utilize grupos

por ficheiro ou pasta para gerir o acesso com menos
entradas.
Limites de partilha de dados

A Azure Data Share permite às organizações partilhar em conjunto e de forma segura dados com os seus clientes e
parceiros.
REC URSO L IM IT E
Número máximo de recursos de partilha de dados por 50

subscrição do Azure
Número máximo de ações enviadas por recurso data Share 100
Número máximo de ações recebidas por recurso data Share 100

REC URSO L IM IT E
Número máximo de convites por ação enviada 100
Número máximo de subscrições de ações por ação enviada 100
Número máximo de conjuntos de dados por ação 100
Número máximo de horários instantâneos por ação 1
Limites do serviço de migração de bases de dados

O Azure Database Migration Service é um serviço totalmente gerido para permitir migrações perfeitas de várias
fontes de base de dados para plataformas de dados Azure com o mínimo de tempo de inatividade.
Número máximo de serviços por 2 Para solicitar um aumento deste limite,

subscrição, por região o suporte de contato.
Limites da grelha de eventos

Os seguintes limites aplicam-se aos tópicos do sistema Azure Event Grid e tópicos personalizados, e não domínios
de eventos.
REC URSO L IM IT E
Tópicos personalizados por subscrição do Azure 100
Assinaturas de eventos por tópico 500
Taxa de publicação para um tópico personalizado (ingresso) 5.000 eventos por segundo por tópico
Tamanho do evento 1 MB. As operações são carregadas em incrementos de 64 KB.

Assim, eventos acima de 64 KB incorrerão em acusações de
operações como se fossem múltiplos eventos. Por exemplo,
um evento de 130 KB incorreria em operações como se
fossem 3 eventos separados.
Tópicos por domínio de evento 100 000
Assinaturas de eventos por tópico dentro de um domínio 500
Assinaturas de eventos de âmbito de domínio 50
Taxa de publicação para um domínio de evento (ingress) 5.000 eventos por segundo
Domínios de eventos por subscrição azure 100
Conexões de ponto final privados por tópico ou domínio 64
Regras ip firewall por tópico ou domínio 16

Limites de Centros de Eventos
As tabelas a seguir fornecem quotas e limites específicos aos Hubs de Eventos Azure. Para obter informações sobre
os preços dos Event Hubs, consulte os preços do Event Hubs.
Os seguintes limites são comuns em níveis básicos e padrão.
L IM IT E Â M B ITO N OTA S VA LO R
Número de espaços de Subscrição - 100

nomes de Centros de
Eventos por subscrição
Número de centros de Espaço de Nomes Os pedidos subsequentes 10

eventos por espaço de nome para a criação de um novo
centro de eventos são
rejeitados.
Número de divisórias por Entidade - 32

centro de eventos
Tamanho máximo de um Entidade - 256 caracteres

nome de hub de evento
Tamanho máximo de um Entidade - 256 caracteres

nome de grupo de
consumidores
Número de recetores não- Entidade - 5

época por grupo de
consumidores
Unidades de produção Espaço de Nomes Exceder o limite de unidade 20

máxima de produção faz com que os
seus dados sejam
estrangulados e gera uma
exceção ocupada do
servidor. Para solicitar um
maior número de unidades
de produção para um nível
Standard, apresente um
pedido de suporte. Unidades
de produção adicionais estão
disponíveis em blocos de 20
numa base de compra
comprometida.
Número de regras de Espaço de Nomes Os pedidos subsequentes de 12

autorização por espaço de criação de regras de
nome autorização são rejeitados.
Número de chamadas para o Entidade - 50 por segundo

método
GetRuntimeInformation
Número de regras de rede Entidade - 128

virtual (VNet) e IP Config
Centros de Eventos Básicos e Standard - quotas e limites

L IM IT E Â M B ITO N OTA S B Á SIC O STA N DA RD
Tamanho máximo do Entidade 256 KB 1 MB

evento Event Hubs
Número de grupos de Entidade 1 20

consumidores por
centro de eventos
Número de ligações Espaço de Nomes Os pedidos 100 5000

AMQP por espaço de subsequentes de
nome ligações adicionais são
rejeitados e uma
exceção é recebida
pelo código de
chamada.
Período máximo de Entidade 1 dia 1-7 dias

retenção dos dados
do evento
Apache Kafka Espaço de Nomes Aplicações de streams Não Sim

viabilizar espaço de de espaço de nome
nome de centros de eventos
usando o protocolo
Kafka
Captura Entidade Quando ativados, Não Sim

micro-lotes no
mesmo fluxo
Centros de Eventos Dedicados - quotas e limites

A oferta dedicada do Event Hubs é faturada a um preço mensal fixo, com um mínimo de 4 horas de utilização. O
tier dedicado oferece todas as características do plano Standard, mas com capacidade de escala empresarial e
limites para clientes com cargas de trabalho exigentes.
F UN C IO N A L IDA DE L IM IT ES
Largura de banda 20 CUs
Espaços de nomes 50 por CU
Hubs de Eventos 1000 por espaço de nome
Eventos ingressos Incluído
Tamanho da mensagem 1 MB
Partições 2000 por CU
Grupos de consumidores Sem limite por CU, 1000 por centro de eventos
Conexões intermediadas 100 K incluído
Retenção de mensagens 90 dias, 10 TB incluídos por CU

F UN C IO N A L IDA DE L IM IT ES
Captura Incluído
Limites do Gestor de Identidade

Identidades geridas atribuídas ao utilizador Quando cria identidades geridas atribuídas ao

utilizador, apenas são suportados caracteres
alfanuméricos (0-9, a-z e A-Z) e o hífen (-) suportados.
Para que a atribuição a uma máquina virtual ou à
escala de máquina virtual funcione corretamente, o
nome está limitado a 24 caracteres.
Se utilizar a extensão da máquina virtual de identidade
gerida, o limite suportado é de 32 identidades geridas
pelo utilizador. Sem a extensão da máquina virtual de
identidade gerida, o limite suportado é de 512
identidades atribuídas ao utilizador.
Limites centrais IoT

A IoT Central limita o número de aplicações que pode implementar numa subscrição de 10. Se precisar de
aumentar este limite, contacte o suporte da Microsoft.
Limites do Hub IoT

A tabela seguinte enumera os limites associados aos diferentes níveis de serviço S1, S2, S3 e F1. Para obter
informações sobre o custo de cada unidade em cada nível, consulte o preço do Hub Azure IoT.
REC URSO S1 STA N DA RD S2 STA N DA RD S3 STA N DA RD F 1 GRAT UITO
Mensagens/dia 400,000 6,000,000 300,000,000 8,000
Máximo de unidades 200 200 10 1
NOTE
Se antecipar a utilização de mais de 200 unidades com um hub de nível S1 ou S2 ou 10 unidades com um hub de nível S3,
contacte o Microsoft Support.
A tabela que se segue enumera os limites aplicáveis aos recursos do IoT Hub.
REC URSO L IM IT E
Máximo de hubs IoT pagos por subscrição do Azure 50
Máximo de hubs IoT gratuitos por subscrição do Azure 1
Número máximo de caracteres em identificação de dispositivo 128

REC URSO L IM IT E
Número máximo de identidades de dispositivos 1,000

devolvidas numa única chamada
Retenção máxima de mensagem do Hub IoT para mensagens 7 dias

do dispositivo para a cloud
Tamanho máximo da mensagem do dispositivo para a cloud 256 KB
Tamanho máximo do batch do dispositivo para a cloud AMQP e HTTP: 256 KB para todo o lote
MQTT: 256 KB para cada mensagem
Máximo de mensagens no batch do dispositivo para a cloud 500
Tamanho máximo da mensagem da cloud para o dispositivo 64 KB
TTL máximo das mensagens da cloud para o dispositivo 2 dias
Contagem máxima de entrega da cloud para o dispositivo 100

mensagens
Profundidade máxima de fila nuvem-dispositivo por 50

dispositivo
Contagem máxima de entrega para mensagens de 100

comentários
em resposta a uma mensagem da cloud para o dispositivo
TTL máximo para mensagens de comentários em 2 dias

resposta a uma mensagem da cloud para o dispositivo
Tamanho máximo do dispositivo duplo 8 KB para a secção de etiquetas, e 32 KB para as secções de

propriedades desejadas e reportadas cada
Comprimento máximo da chave de corda gémea do 1 KB

dispositivo
Comprimento máximo do valor de corda gémea do dispositivo 4 KB
Profundidade máxima do objeto no dispositivo duplo 10
Tamanho máximo do payload de método direto 128 KB
Retenção máxima de histórico de tarefas 30 dias
Máximo de tarefas simultâneas 10 (para S3), 5 (para S2), 1 (para S1)
Máximo de pontos finais adicionais 10 (para S1, S2 e S3)
Regras de encaminhamento máximo de mensagens 100 (para S1, S2 e S3)
Número máximo de fluxos de dispositivos ligados 50 (apenas para S1, S2, S3 e F1)
simultaneamente
REC URSO L IM IT E
Transferência máxima de dados de fluxo de dispositivos 300 MB por dia (apenas para S1, S2, S3 e F1)
NOTE
Se precisar de mais de 50 hubs IoT pagos numa subscrição do Azure, contacte o Microsoft Support.
NOTE
Atualmente, o número total de dispositivos mais módulos que podem ser registados num único hub IoT está limitado a
1.000.000. Se quiser aumentar este limite, contacte o Suporte da Microsoft.
Os pedidos de aceleração do IoT Hub quando as seguintes quotas são excedidas.
L IM ITA Ç Ã O VA LO R P O R H UB
Operações de registo de identidade 83,33/seg/unidade (5.000/min/unidade) (para S3).

(criar, recuperar, listar, atualizar e eliminar), 1.67/seg/unidade (100/min/unidade) (para S1 e S2).
importar/exportar de forma individual ou em massa
Ligações do dispositivo 6.000/seg/unidade (para S3), 120/seg/unidade (para S2),

12/seg/unidade (para S1).
Mínimo de 100/seg.
Envios do dispositivo para a cloud 6.000/seg/unidade (para S3), 120/seg/unidade (para S2),
12/seg/unidade (para S1).
Mínimo de 100/seg.
Envios da cloud para o dispositivo 83,33/seg/unidade (5.000/min/unidade) (para S3),

1.67/seg/unidade (100/min/unidade) (para S1 e S2).
Receções da cloud para o dispositivo 833,33/seg/unidade (50.000/min/unidade) (para S3),

16,67/sec/unidade (1.000/min/unidade) (para S1 e S2).
Operações de carregamento de ficheiros 83.33 iniciações de upload de ficheiros/sec/unidade

(5.000/min/unidade) (para S3), 1.67 iniciações de upload de
ficheiros/sec/unidade (100/min/unidade) (para S1 e S2).
10.000 URIs SAS podem estar fora para uma conta de
Armazenamento Azure de uma só vez.
10 SAS URIs/dispositivo podem ficar fora de uma só vez.
Métodos diretos 24 MB/seg/unidade (para S3), 480 KB/seg/unidade (para S2),

160 KB/seg/unidade (para S1).
Baseado no tamanho do medidor de estrangulamento de 8
KB.
Leituras de dispositivo duplo 500/seg/unidade (para S3), Máximo de 100/seg ou

10/seg/unidade (para S2), 100/seg (para S1)
Atualizações de dispositivo duplo 250/seg/unidade (para S3), Máximo de 50/seg ou

5/seg/unidade (para S2), 50/seg (para S1)
L IM ITA Ç Ã O VA LO R P O R H UB
Operações de tarefas 83,33/seg/unidade (5.000/min/unidade) (para S3),

(criar, atualizar, listar e eliminar) 1.67/seg/unidade (100/min/unidade) (para S2),
1,67/seg/unidade (100/min/unidade) (para S1).
Débito de operação tarefas por dispositivo 50/seg/unidade (para S3), máximo de 10/seg ou
1/seg/unidade (para S2), 10/seg (para S1).
Taxa de iniciação do fluxo do dispositivo 5 novos fluxos/seg (apenas para S1, S2, S3 e F1).
Limites de serviço de fornecimento de dispositivos ioT hub

A tabela que se segue enumera os limites aplicáveis aos recursos do Serviço de Provisionamento de Dispositivos
Hub Azure IoT.
REC URSO L IM IT E
Serviços máximos de fornecimento de dispositivos por 10

subscrição do Azure
Número máximo de matrículas 1 000 000
Número máximo de inscrições 1 000 000
Número máximo de grupos de matrícula 100
Número máximo de AE 25
Número máximo de centros ioT ligados 50
Tamanho máximo da mensagem 96 KB
NOTE
Para aumentar o número de inscrições e inscrições no seu serviço de provisionamento, contacte o Microsoft Support.
NOTE
O aumento do número máximo de AE não é suportado.
O Serviço de Fornecimento de Dispositivos acelera os pedidos quando as seguintes quotas são excedidas.
L IM ITA Ç Ã O VA LO R P O R UN IDA DE
Operações 200/min/serviço
Registos de dispositivos 200/min/serviço
Operação de sondagem de dispositivos 5/10 seg/dispositivo

Limites do cofre-chave
Principais transações (transações máximas permitidas em 10 segundos, por cofre por região 1):
C H AVE H SM C H AVE DE SO F T WA RE
C H AVE H SM TO DA S A S O UT RA S C H AVE DE SO F T WA RE TO DA S A S O UT RA S
T IP O DE C H AVE C H AVE C RIA R T RA N SA Ç Õ ES C H AVE C RIA R T RA N SA Ç Õ ES
RSA 2.048-bit 5 1,000 10 2.000
RSA 3.072-bit 5 250 10 500
RSA 4.096-bit 5 125 10 250
ECC P-256 5 1,000 10 2.000
ECC P-384 5 1,000 10 2.000
ECC P-521 5 1,000 10 2.000
ECC SECP256K1 5 1,000 10 2.000
NOTE
Na tabela anterior, vemos que para as chaves de software RSA de 2.048 bits, são permitidas 2.000 transações GET por 10
segundos. Para rsa 2.048 bits HSM-keys, 1.000 transações GET por 10 segundos são permitidas.
Os limiares de estrangulamento são ponderados, e a aplicação da lei está na sua soma. Por exemplo, como mostrado na
tabela anterior, quando executa operações GET em chaves RSA HSM, é oito vezes mais caro usar teclas de 4.096 bits em
comparação com 2.048 bits. Isso é porque 1.000/125 = 8.
Num intervalo de 10 segundos, um cliente azure key vault só pode 429 fazer uma das seguintes operações antes de
encontrar um código de estado HTTP estrangulado:
2.000 RSA 2.048 bits-chave de software GET transações
1.000 RSA 2.048 bits HSM-key GET transações
125 RSA 4.096 bits HSM-key GET transações
124 RSA 4.096-bits hSM-key GET e 8 rSA 2.048 bits HSM-key GET transações
Segredos, chaves de conta de armazenamento geridas e transações de cofres:

T RA N SA Ç Õ ES M Á XIM A S P ERM IT IDA S EM 10 SEGUN DO S, P O R
T IP O DE T RA N SA Ç Õ ES C O F RE P O R REGIÃ O 1
Todas as transações 2.000
Para obter informações sobre como lidar com a estrangulamento quando estes limites são ultrapassados, consulte
a orientação de estrangulamento do Cofre-Chave Azure.
1 Um limite de subscrição para todos os tipos de transações é cinco vezes por limite de cofre chave. Por exemplo,
outras transações HSM por subscrição estão limitadas a 5.000 transações em 10 segundos por subscrição.
Integração de Ligações Privadas Azure
REC URSO L IM IT E
Pontos finais privados por cofre chave 64
Cofres chave com pontos finais privados por subscrição 64
Limites dos Serviços de Mídia

NOTE
Para recursos que não estão fixos, abra um bilhete de apoio para pedir um aumento das quotas. Não crie contas adicionais
da Azure Media Services numa tentativa de obter limites mais elevados.
Limites de conta
REC URSO L IM IT E P REDEF IN IDO
Contas de Serviços de Media numa única subscrição 25 (fixo)
Limites de ativos
Ativos por conta de Serviços de Media 1 000 000
Limites de armazenamento (meios)

Tamanho dos ficheiros Em alguns cenários, existe um limite para o tamanho máximo
dos ficheiros suportados para o processamento em Serviços
de Media. (1)
Contas de armazenamento 100(2) (fixo)
1 O tamanho máximo suportado para uma única bolha é atualmente de até 5 TB no Armazenamento De Blob
Azure. Limites adicionais aplicam-se nos Serviços de Media com base nos tamanhos vm que são utilizados pelo
serviço. O limite de tamanho aplica-se aos ficheiros que envia e também aos ficheiros que são gerados em
resultado do processamento de Serviços de Media (codificação ou análise). Se o seu ficheiro de origem for
superior a 260 GB, o seu Trabalho provavelmente falhará.
A tabela seguinte mostra os limites das unidades reservadas aos meios de comunicação S1, S2 e S3. Se o seu
ficheiro fonte for maior do que os limites definidos na tabela, o seu trabalho de codificação falha. Se codificar
fontes de resolução 4K de longa duração, é obrigado a utilizar unidades reservadas aos meios de comunicação S3
para obter o desempenho necessário. Se tiver um conteúdo 4K maior do que o limite de 260 GB nas unidades
reservadas aos meios de comunicação S3, abra um bilhete de apoio.
T IP O DE UN IDA DE RESERVA DO A O S M EIO S DE

C O M UN IC A Ç Ã O TA M A N H O M Á XIM O DE EN T RA DA ( GB )
S1 26
S2 60
T IP O DE UN IDA DE RESERVA DO A O S M EIO S DE
C O M UN IC A Ç Ã O TA M A N H O M Á XIM O DE EN T RA DA ( GB )
S3 260
2 As contas de armazenamento devem ser da mesma assinatura Azure.

Limites de emprego (codificação & análise )
Empregos por conta de Serviços de Media 500.000 (3) (fixo)
Inputs de emprego por Job 50 (fixo)
Saídas de emprego por Job 20 (fixo)
Transforma-se por conta de Serviços de Media 100 (fixo)
Transforme as saídas numa Transformação 20 (fixo)
Ficheiros por entrada de trabalho 10 (fixo)
3 Este número inclui trabalhos em fila, acabados, ativos e cancelados. Não inclui empregos apagados.
Qualquer registo de emprego na sua conta com mais de 90 dias será automaticamente eliminado, mesmo que o
número total de registos esteja abaixo da quota máxima.
Limites de streaming ao vivo
Eventos ao Vivo (4) por conta de Serviços de Media 5
Saídas ao vivo por evento ao vivo 3 (5)
Duração da saída de Max Live Tamanho da janela DVR
4 Para obterinformações detalhadas sobre as limitações do Evento Ao Vivo, consulte a comparação e limitaçõesdos
tipos de eventos ao vivo .
5 Saídas ao vivo começam na criação e param quando eliminados.
Limites de entrega de & de embalagem
Pontos Finais de Streaming (parados ou em execução) por 2 (fixo)

conta de Media Services
Filtros do Manifesto Dinâmico 100
Políticas de Transmissão em Fluxo 100 (6)
Localizadores de streaming exclusivos associados a um Ativo 100(7) (fixo)

ao mesmo tempo
6
6 Ao utilizar
uma Política de Streamingpersonalizada, deve conceber um conjunto limitado de tais políticas para a
sua conta de Serviço de Media e reutilizá-las para os seus Localizadores de Streaming sempre que forem
necessárias as mesmas opções e protocolos de encriptação. Não deve criar uma nova Política de Streaming para
cada Localizador de Streaming.
7 Os localizadores de streaming não foram concebidos para gerir o controlo de acesso por utilizador. Para conceder
direitos de acesso diferentes a utilizadores individuais, utilize soluções de Gestão de Direitos Digitais (Digital Rights
Management, DRM).
Limites de proteção
Opções por Política chave de conteúdo 30
Licenças por mês para cada um dos tipos de DRM no serviço 1 000 000
de entrega chave de Serviços de Media por conta
Bilhete de apoio
Para recursos que não estão fixos, pode pedir que as quotas sejam aumentadas, abrindo um bilhete de apoio.
Incluir informações detalhadas no pedido sobre as alterações de quota desejadas, cenários de caso de utilização e
regiões necessárias.
Não crie contas dos Serviços de Multimédia do Azure adicionais numa tentativa de obter limites superiores.
Serviços de Multimédia v2 (legados)
Para limites específicos dos Serviços de Mídia v2 (legado), consulte Os Serviços de Mídia v2 (legado)
Limites de Serviços Móveis

ESC A L Ã O GRAT UITO B Á SIC O STA N DA RD
Chamadas à API 500 000 1,5 milhões por unidade 15 milhões por unidade
Dispositivos ativos 500 Ilimitado Ilimitado
Escala N/D Até 6 unidades Unidades ilimitadas
Notificações push Azure Notification Hubs Free Centros de Notificação Nível Nível padrão de Centros de
tier incluído, até 1 milhão de básico incluído, até 10 Notificação incluído, até 10
pushs milhões de pushs milhões de pushs
Mensagens em tempo real/ Limitado 350 por serviço móvel Ilimitado

Tomadas web
Sincronizações offline Limitado Incluído Incluído
Tarefas agendadas Limitado Incluído Incluído
Base de Dados Azure SQL 20 MB incluídos 20 MB incluídos 20 MB incluídos

(necessária)
Tarifas padrão aplicam-se
para capacidade adicional
Capacidade do CPU 60 minutos por dia Ilimitado Ilimitado

Transferência de dados de 165 MB por dia Incluído Incluído

saída (capotamento diário)
Para obter mais informações sobre limites e preços, consulte os preços dos Serviços Móveis Azure.
Limites de autenticação multi-factor

Número máximo de endereços IP ou 0 50

intervalos de IP fidedignos por
subscrição
Lembre-se dos meus dispositivos, 14 60

número de dias
Número máximo de senhas de aplicação 0 Sem limite
Permitir X tentativas durante a 1 99

chamada MFA
Segundos de tempo de tempo 60 600

inversivada de mensagem de texto
bidirecional
Segundos de omissão de uso individual 300 1.800

predefinidos
Bloquear a conta de utilizador após X Não definido 99

negações consecutivas do MFA
Repor contador de bloqueio da conta Não definido 9,999

após X minutos
Desbloquear a conta após X minutos Não definido 9,999
Limites de rede
Limites de networking - Gestor de Recursos Azure
Os seguintes limites aplicam-se apenas aos recursos de networking geridos através do Gestor de Recursos
Azure por região por subscrição. Saiba como visualizar o seu uso atual de recursos contra os seus limitesde
subscrição .
NOTE
Recentemente aumentámos todos os limites de incumprimento para os seus limites máximos. Se não houver uma coluna de
limite máximo, o recurso não tem limites ajustáveis. Se teve estes limites aumentados pelo suporte no passado e não vê
limites atualizados nas tabelas seguintes, abra um pedido de apoio ao cliente online sem custos
REC URSO L IM IT E
Redes virtuais 1,000
Sub-redes por rede virtual 3.000
Peerings de rede virtual por rede virtual 500
Gateways de rede virtuais (gateways VPN) por rede virtual 1
Gateways de rede virtual (gateways ExpressRoute) por rede 1

virtual
Servidores DNS por rede virtual 20
Endereços IP privados por rede virtual 65 536
Endereços IP privados por interface de rede 256
Endereços IP privados por máquina virtual 256
Endereços IP públicos por interface de rede 256
Endereços IP públicos por máquina virtual 256
Fluxos simultâneos de TCP ou UDP por NIC de uma máquina 500 000
virtual ou exemplo de função
Cartões de interface de rede 65 536
Grupos de Segurança de Rede 5000
Regras do NSG por NSG 1,000
Endereços IP e gamas especificadas para fonte ou destino 4000

num grupo de segurança
Grupos de segurança de aplicações 3.000
Grupos de segurança de aplicações por configuração IP, por 20

NIC
Configurações IP por grupo de segurança de aplicações 4000
Grupos de segurança de aplicações que podem ser 100

especificados dentro de todas as regras de segurança de um
grupo de segurança de rede
Tabelas de rotas definidas pelo utilizador 200
Rotas definidas pelo utilizador por tabela de rotas 400
Certificados de raiz ponto-a-local por Gateway VPN Azure 20

REC URSO L IM IT E
TAPs de rede virtual 100
Configurações TAP de interface de rede por rede virtual TAP 100
Limites de endereços IP públicos
Endereços IP públicos1 10 para o Básico. Contacte o suporte.
Endereços IP públicos estáticos1 10 para o Básico. Contacte o suporte.
Endereços IP públicos padrão1 10 Contacte o suporte.
Prefixos de IP Públicos limitado pelo número de IPs Públicos Contacte o suporte.

Standard numa subscrição
Comprimento de prefixo ip público /28 Contacte o suporte.
1 Os limites de predefinição para endereços IP públicos variam

por tipo de categoria de oferta, tais como Free Trial,
Pay-As-You-Go, CSP. Por exemplo, o padrão para subscrições do Acordo Empresarial é de 1000.
Limites de equilíbrio de carga
Os seguintes limites só se aplicam aos recursos de rede geridos através do Azure Resource Manager por região
por subscrição. Saiba como visualizar o seu uso atual de recursos contra os seus limitesde subscrição .
Balanceador de Carga Padrão
REC URSO L IM IT E
Balanceadores de carga 1,000
Regras por recurso 1500
Regras por NIC (em todos os IPs num NIC) 300
Configurações IP frontend 600
Tamanho da piscina de backend 1.000 configurações IP, rede virtual única
Recursos de backend p o r Lo ad B alan cer 1 150
Portas de alta disponibilidade 1 por frontend interno
Regras de saída por Balancer de Carga 600
Tempo limite de inatividade da TCP 4 minutos/30 minutos
1 O limite é de até 150recursos, em qualquer combinação de recursos de máquinas virtuais autónomas, recursos
definidos de disponibilidade e grupos de colocação de escala de máquina virtual.
Balanceador de Carga Básico
REC URSO L IM IT E
Balanceadores de carga 1,000
Regras por recurso 250
Regras por NIC (em todos os IPs num NIC) 300
Configurações IP frontend 200
Tamanho da piscina de backend 300 configurações IP, conjunto de disponibilidade única
Conjuntos de disponibilidade por Balancer de carga 150
Os seguintes limites aplicam-se apenas aos recursos de networking geridos através do modelo de implantação
clássico por subscrição. Saiba como visualizar o seu uso atual de recursos contra os seus limitesde subscrição .
Redes virtuais 100 100
Sites de rede local 20 50
Servidores DNS por rede virtual 20 20
Endereços IP privados por rede virtual 4,096 4,096
Fluxos simultâneos de TCP ou UDP por 500.000, até 1.000.000 para dois ou 500.000, até 1.000.000 para dois ou
NIC de uma máquina virtual ou mais NICs. mais NICs.
exemplo de função
Grupos de Segurança de Rede (NSGs) 200 200
Regras do NSG por NSG 1,000 1,000
Tabelas de rotas definidas pelo utilizador 200 200
Rotas definidas pelo utilizador por 400 400

tabela de rotas
Endereços IP públicos (dinâmico) 500 500
Endereços IP públicos reservados 500 500
VIP público por implementação 5 Contactar o suporte
VIP privado (equilíbrio interno de carga) 1 1

por implantação
Listas de controlo de acesso de ponto 50 50

final (ACLs)
Limites ExpressRoute
REC URSO L IM IT E
Circuitos ExpressRoute por subscrição 10
Circuitos ExpressRoute por região por subscrição, com Gestor 10

de Recursos Azure
Número máximo de rotas anunciadas para o azure private 4000

peering com ExpressRoute Standard
Número máximo de rotas anunciadas para o azure private 10,000

peering com add-on ExpressRoute Premium
Número máximo de rotas anunciadas a partir do espaço de 200

endereçoS VNet para uma ligação ExpressRoute
Número máximo de rotas anunciadas para a Microsoft a 200

espreitar com o ExpressRoute Standard
Número máximo de rotas anunciadas para a Microsoft peering 200

com add-on ExpressRoute Premium
Número máximo de circuitos ExpressRoute ligados à mesma 4

rede virtual no mesmo local de observação
Número máximo de circuitos ExpressRoute ligados à mesma 4

rede virtual em diferentes locais de observação
Número de ligações de rede virtual permitidas por circuito Consulte o Número de redes virtuais por tabela de circuitos
ExpressRoute ExpressRoute.
Número de redes virtuais por circuito ExpressRoute
N ÚM ERO DE L IGA Ç Õ ES DE REDE N ÚM ERO DE L IGA Ç Õ ES DE REDE

TA M A N H O DO C IRC UITO VIRT UA L PA RA STA N DA RD VIRT UA L C O M A DD- O N P REM IUM
50 Mbps 10 20
100 Mbps 10 25
200 Mbps 10 25
500 Mbps 10 40
1 Gbps 10 50
2 Gbps 10 60
5 Gbps 10 75
10 Gbps 10 100
40 Gbps* 10 100
100 Gbps* 10 100

*100 Gbps ExpressRoute Direct Apenas
NOTE
As ligações Global Reach contam contra o limite de ligações de rede virtual por Circuito ExpressRoute. Por exemplo, um
Circuito Premium de 10 Gbps permitiria 5 ligações Global Reach e 95 ligações às Ligações ExpressRoute Gateways ou 95
ligações Global Reach e 5 ligações aos Gateways ExpressRoute ou qualquer outra combinação até ao limite de 100 ligações
para o circuito.
Limites de WAN virtuais

REC URSO L IM IT E
Centros wan virtuais por região 1
Centros wan virtuais por wan virtual Regiões do Azure
Ligações VPN (ramo) por hub 1,000
Ligações VNet por hub 500
Utilizadores ponto-a-site por hub 10,000
Produção agregada por gateway Virtual WAN VPN 20 Gbps
Entrada por ligação VVpN Virtual WAN (2 túneis) 2 Gbps com 1 túnel Gbps/IPsec
Produção agregada por gateway Virtual WAN ExpressRoute 20 Gbps
Limites do Gateway de Aplicação

O quadro a seguir aplica-se aos SKUs V1, V2, Standard e WAF, salvo indicação em contrário.
Gateway de Aplicação do Azure 1.000 por subscrição
Configurações IP front-end 2 1 pública e 1 privada
Portas frontais 1001
Piscinas de endereços de back-end 1001
Servidores de back-end por piscina 1200
Ouvintes http 2001 Limitado a 100 ouvintes ativos que

estão a encaminhar o tráfego. Ouvintes
ativos = número total de ouvintes -
ouvintes não ativos.
Se uma configuração predefinida dentro
de uma regra de encaminhamento for
definida para o tráfego de rota (por
exemplo, tem um ouvinte, uma piscina
de backend e definições HTTP) então
isso também conta como ouvinte.
REGRAS de equilíbrio de carga http 1001
Definições de HTTP de back-end 1001
Instâncias por gateway V1 SKU - 32

V2 SKU - 125
Certificados SSL 1001 1 por ouvinte HTTP
Tamanho máximo do certificado SSL V1 SKU - 10 KB

V2 SKU - 16 KB
Certificados de autenticação 100
Certificados de raiz fidedignos 100
Pedir tempo mínimo 1 segundo
Pedir tempo máximo 24 horas
Número de sites 1001 1 por ouvinte HTTP
Mapas de URL por ouvinte 1
Regras máximas baseadas em caminhos 100

por mapa de URL
Configurações de redirecionamento 1001
Conexões WebSocket simultâneas Gateways médios 20k

Grandes portas 50k
Comprimento máximo do URL 32KB
Tamanho máximo do cabeçalho para 4KB

HTTP/2
Tamanho máximo do upload de ficheiro, 2GB

Standard
Tamanho máximo do carregamento de Portais V1 Medium WAF, 100 MB

ficheiros WAF Portais v1 grandes WAF, 500 MB
V2 WAF, 750 MB
Limite de tamanho do corpo waf, sem 128 KB

ficheiros
Regras máximas de costume waf 100
Exclusões máximas de WAF 100
1 No caso de SKUs ativadas por WAF, recomendamos que limite o número de recursos a 40 para um desempenho
ótimo.
Limites do Observador de Rede
Observador de Rede do Azure 1 por região O Network Watcher é criado para

permitir o acesso ao serviço. Só é
necessária uma instância do
Observador de Rede por subscrição por
região.
Sessões de captura de pacotes 10.000 por região Número de sessões apenas, não salvas
capturas.
Limites do Private Link

Os seguintes limites aplicam-se à ligação privada azure:
REC URSO L IM IT E
Número de pontos finais privados por rede virtual 1000
Número de pontos finais privados por subscrição 64000
Número de serviço de ligação privada por subscrição 800
Número de Configurações IP num serviço de ligação privada 8 (Este número destina-se aos endereços IP NAT utilizados por
PLS)
Número de pontos finais privados no mesmo serviço de 1000

ligação privada
Número de pontos finais privados por cofre chave 64
Número de cofres-chave com pontos finais privados por 64

subscrição
Limites do Gestor de Tráfego

REC URSO L IM IT E
Perfis por subscrição 200
Pontos finais por perfil 200
Limites do Bastião Azure

REC URSO L IM IT E
Conexões pDR simultâneas 25*
Conexões SSH simultâneas 50**
*Pode variar devido a outras sessões de RDP em curso ou outras sessões de SSH em curso.
**Pode variar se existirem ligações RDP existentes ou utilização de outras sessões de SSH em curso.
Limites de DNS de Azure
Zonas públicas de DNS
REC URSO L IM IT E
Zonas Públicas dNS por subscrição 250 1
Recorde seleções por zona pública de DNS 10.000 1
Recordes por recorde estabelecidos na zona pública de DNS 20
Número de registos da Alias para um único recurso Azure 20
Zonas privadas de DNS por subscrição 1000
Recorde seleções por zona privada de DNS 25 000
Recordes por recorde estabelecidos para zonas privadas de 20

DNS
Links de rede virtual por zona privada de DNS 1000
Ligações de Redes Virtuais por zonas privadas de DNS com 100

registo automático ativado
Número de zonas privadas de DNS a que uma rede virtual 1

pode ficar ligada com registo automático ativado
Número de zonas privadas de DNS uma rede virtual pode ficar 1000
ligada
Número de consultas de DNS que uma máquina virtual pode 500 2

enviar para O DNS Azure resolver, por segundo
Número máximo de consultas de DNS em fila (resposta 200 2

pendente) por máquina virtual
1 Se precisar de aumentar estes limites, contacte o Suporte Azure.

2 Estes limites são aplicados a todas as máquinas virtuais individuais e não ao nível da rede virtual. As consultas de
DNS que excedem estes limites são retiradas.

Limites de Firewall Azure
REC URSO L IM IT E
Débito de dados 30 Gbps1
Regras 10,000. Todos os tipos de regras combinados.
Regras máximas de ADN 298

Se o protocolo de uma regra estiver configurado tanto para
tcp como uDP, conta como duas regras.
Tamanho mínimo da AzureFirewallSubnet /26

REC URSO L IM IT E
Gama portuária nas regras de rede e aplicação 1 - 65535
Endereços IP públicos 250 no máximo. Todos os endereços IP públicos podem ser

usados nas regras de ADN e todos contribuem para as portas
SNAT disponíveis.
Endereços IP em Grupos IP 50 grupos IP ou menos: máximo 5000 endereços IP

individuais cada um por instância de firewall.
51 - 100 Grupos IP: 500 endereços IP individuais cada um por
instância de firewall.
Para mais informações consulte grupos IP (pré-visualização)

em Firewall Azure
Tabela de rota Por padrão, o AzureFirewallSubnet tem uma rota de 0.0.0.0/0

com o valor NextHopType definido para a Internet .
O Azure Firewall deve ter conectividade direta com a Internet.

Se o seu AzureFirewallSubnet aprender uma rota padrão para
a sua rede no local via BGP, deve sobrepor-se a isso com um
UDR 0.0.0.0/0 com o valor NextHopType definido como
Internet para manter a conectividade direta da Internet. Por
padrão, o Azure Firewall não suporta túneis forçados para
uma rede no local.
No entanto, se a sua configuração necessitar de túneis

forçados para uma rede no local, a Microsoft irá apoiá-la caso
a caso. Contacte o Suporte para que possamos rever o seu
caso. Se for aceite, permitiremos a sua subscrição e
garantiremos a manutenção da conectividade de Firewall
Internet necessária.
1 Se precisar de aumentar estes limites, contacte o Suporte Azure.

Limites de serviço da porta da frente Azure
REC URSO L IM IT E
Recursos da Porta Da Frente Azure por subscrição 100
Anfitriões front-end, que inclui domínios personalizados por 500

recurso
Regras de encaminhamento por recurso 500
Piscinas de back-end por recurso 50
Back ends por piscina de back-end 100
Padrões de caminho para combinar com uma regra de 25

encaminhamento
URLs em uma única chamada de purga cache 100
Regras personalizadas de firewall de aplicação web por política 100

REC URSO L IM IT E
Política de firewall de aplicações web por subscrição 100
Condições de correspondência de firewall de aplicação web 10

por regra personalizada
Intervalos de endereçoip de firewall de aplicação web por 600

condição de jogo
Valores de correspondência de firewall de firewall de aplicação 10

web por condição de jogo
Comprimento de valor de correspondência de linha de firewall 256

de aplicação web
Firewall de aplicação web POST comprimento de nome do 256

parâmetro do corpo
Comprimento do nome do cabeçalho http da firewall da 256

aplicação web
Comprimento do nome do cookie de firewall da aplicação web 256
Firewall de aplicação web HTTP solicitar tamanho do corpo 128 KB

inspecionado
Comprimento do corpo personalizado de resposta da firewall 2 KB

da aplicação web
Valores de timeout
Cliente para porta da frente
A Porta da Frente tem um tempo limite de ligação TCP inativo de 61 segundos.
Porta da Frente para aplicação back-end
Se a resposta for uma resposta em pedaços, um 200 é devolvido se ou quando o primeiro pedaço for recebido.
Depois de o pedido HTTP ser encaminhado para a parte de trás, a Porta da Frente aguarda 30 segundos pelo
primeiro pacote a partir da parte de trás. Depois devolve um erro 503 ao cliente. Este valor é configurável
através do campo sendRecvTimeoutSeconds na API.
Para cenários de cache, este tempo não é configurável e por isso, se um pedido for cache e demorar mais
de 30 segundos para o primeiro pacote da Porta da Frente ou do backend, então um erro de 504 é
devolvido ao cliente.
Depois de o primeiro pacote ser recebido a partir da parte de trás, a Porta da Frente espera por 30 segundos
num intervalo de tempo inativo. Depois devolve um erro 503 ao cliente. Este valor de tempo não é configurável.
Porta da frente para o intervalo de sessão tCP de trás para trás é de 90 segundos.
Limite de dados de upload e descarregamento
C O M C O DIF IC A Ç Ã O DE
T RA N SF ERÊN C IA SA B OTA DA ( T EC ) SEM H T T P C H UN K IN G
Transferir Não há limite para o tamanho do Não há limite para o tamanho do

download. download.
C O M C O DIF IC A Ç Ã O DE
T RA N SF ERÊN C IA SA B OTA DA ( T EC ) SEM H T T P C H UN K IN G
Carregar Não há limite, desde que cada O tamanho não pode ser maior que 2
carregamento de CTE seja inferior a 2 GB.
GB.
Outros limites
Tamanho máximo do URL - 8.192 bytes - Especifica o comprimento máximo do URL bruto (esquema + nome de
anfitrião + porta + caminho + cadeia de consulta do URL)
Tamanho máximo da corda de consulta - 4.096 bytes - Especifica o comprimento máximo da corda de consulta,
em bytes.
Tamanho máximo do cabeçalho de resposta HTTP da URL da sonda de saúde - 4.096 bytes - Especificou o
comprimento máximo de todos os cabeçalhos de resposta das sondas de saúde.
Limites dos Centros de Notificação

Empurrões incluídos 1 milhão 10 milhões 10 milhões
Dispositivos ativos 500 200,000 10 milhões
Quota de etiqueta por 60 60 60

instalação ou registo
Para obter mais informações sobre limites e preços, consulte os preços dos Centros de Notificação.
Limites de controlo de acesso baseados em funções

REC URSO L IM IT E
Atribuições de funções para recursos Azure por subscrição 2.000

azure
Atribuições de funções para recursos Azure por grupo de 500

gestão
Papéis personalizados para recursos Azure por inquilino 5000
Papéis personalizados para recursos Azure por inquilino 2.000

(para a Azure Germany e a Azure China 21Vianet)
Limites de autocarros de serviço

A tabela seguinte lista informações de quota específicas para mensagens Azure Service Bus. Para obter
informações sobre preços e outras quotas para o Service Bus, consulte o preço do Ônibus de serviço.
N O M E DE Q UOTA Â M B ITO N OTA S VA LO R

Número máximo de espaços Espaço de nomes Os pedidos subsequentes de 100

de nome básico ou standard espaços de nome sino ou
por subscrição do Azure standard adicionais são
rejeitados pelo portal Azure.
Número máximo de espaços Espaço de nomes Os pedidos subsequentes de 100

de nome Premium por espaços de nome premium
subscrição do Azure adicionais são rejeitados pelo
portal.
Tamanho da fila ou tópico Entidade Definido sobre a criação da 1, 2, 3, 4 GB ou 5 GB.

fila ou tópico.
No Premium SKU, e no SKU
As mensagens recebidas Standard com partição
subsequentes são rejeitadas ativada, a fila máxima ou o
e uma exceção é recebida tamanho do tópico é de 80
pelo código de chamada. GB.
Número de conexões Espaço de nomes Os pedidos subsequentes de NetMessaging: 1.000.

simultâneas num espaço de ligações adicionais são
nome rejeitados e uma exceção é AMQP: 5.000.
recebida pelo código de
chamada. As operações de
REPOUSO não contam para
ligações tcp simultâneas.
Número de pedidos Entidade Os pedidos de receção 5000

simultâneos recebem subsequentes são rejeitados
pedidos numa fila, tópico ou e uma exceção é recebida
entidade de subscrição pelo código de chamada.
Esta quota aplica-se ao
número combinado de
operações de receção
simultâneas em todas as
subscrições sobre um tópico.
Número de tópicos ou filas Espaço de nomes Os pedidos subsequentes de 10.000 para o nível Básico
por espaço de nome criação de um novo tópico ou Standard. O número total
ou fila no espaço de nome de tópicos e filas num
são rejeitados. Como espaço de nome deve ser
resultado, se configurado inferior ou igual a 10.000.
através do portal
Azure,gera-se uma Para o nível Premium, 1.000
mensagem de erro. Se for por unidade de mensagens
chamado pela API de gestão, (MU). Limite máximo é de
uma exceção é recebida pelo 4.000.
código de chamada.
Número de tópicos ou filas Espaço de nomes Os pedidos subsequentes de Níveis básicos e standard:
divididos por espaço de criação de um novo tópico 100.
nome ou fila dividido no espaço de
nome são rejeitados. Como As entidades divididas não
resultado, se configurado são apoiadas no escalão
através do portal Premium.
Azure,gera-se uma
mensagem de erro. Se for Cada fila ou tópico dividido
chamado da API de gestão, conta para a quota de 1.000
a exceção entidades por espaço de
QuotaExceededException nome.
é recebida pelo código de
chamada.
Tamanho máximo de Entidade - 260 caracteres.

qualquer caminho de
entidade de mensagens: fila
ou tópico
Tamanho máximo de Entidade - 50 caracteres.

qualquer nome de entidade
de mensagens: espaço de
nome, subscrição ou regra
de subscrição
Tamanho máximo de um ID Entidade - 128

de mensagem
Tamanho máximo de uma Entidade - 128

identificação de sessão de
mensagem
Tamanho da mensagem para Entidade As mensagens recebidas que Tamanho máximo da

uma fila, tópico ou entidade excedam estas quotas são mensagem: 256 KB para o
de subscrição rejeitadas e uma exceção é nível Standard, 1 MB para o
recebida pelo código de nível Premium.
chamada.
Devido à sobrecarga do
sistema, este limite é inferior
a estes valores.
Tamanho máximo do
cabeçalho: 64 KB.
Número máximo de
propriedades cabeçalho no
saco de propriedade:
byte/int. MaxValue.
Tamanho máximo do imóvel

em bolsa de propriedade:
Sem limite explícito. Limitado
pelo tamanho máximo do
cabeçalho.
Tamanho da propriedade da Entidade A exceção O tamanho máximo da

mensagem para uma fila, SerializationException é propriedade da mensagem
tópico ou entidade de gerada. para cada propriedade é de
subscrição 32.000. O tamanho
acumulado de todas as
propriedades não pode
exceder 64.000. Este limite
aplica-se a todo o cabeçalho
do BrokeredMessage, que
tem propriedades do
utilizador e propriedades do
sistema, tais como
SequenceNumber, Label, e
MessageId.
Número de assinaturas por Entidade Os pedidos subsequentes de 2.000 por tópico para o nível
tópico criação de subscrições Standard.
adicionais para o tópico são
rejeitados. Como resultado,
se configurado através do
portal, é mostrada uma
mensagem de erro. Se for
chamado pela API de gestão,
uma exceção é recebida pelo
código de chamada.
Número de filtros SQL por Entidade Os pedidos subsequentes de 2.000

tópico criação de filtros adicionais
sobre o tema são rejeitados,
e uma exceção é recebida
pelo código de chamada.
Número de filtros de Entidade Os pedidos subsequentes de 100 000

correlação por tópico criação de filtros adicionais
sobre o tema são rejeitados,
e uma exceção é recebida
pelo código de chamada.
Tamanho dos filtros ou ações Espaço de nomes Os pedidos subsequentes de Comprimento máximo da
SQL criação de filtros adicionais cadeia de condição do filtro:
são rejeitados e uma exceção 1.024 (1 K).
é recebida pelo código de
chamada. Comprimento máximo da
corda de ação de regra:
1.024 (1 K).
Número máximo de
expressões por ação de
regra: 32.
Número de regras de Regras Entidade, espaço de nome Os pedidos subsequentes de Número máximo de regras
de Regras de Acesso criação de regras adicionais por entidade tipo: 12.
partilhadopor espaço de são rejeitados e uma exceção
nome, fila ou tópico é recebida pelo código de As regras configuradas num
chamada. espaço de nome do Ônibus
de serviço aplicam-se a
todos os tipos: filas, tópicos.
Número de mensagens por Transação As mensagens recebidas 100

transação adicionais são rejeitadas e
uma exceção que diz "Não Tanto para as operações de
pode enviar mais de 100 envio como de envio de
mensagens numa única Envios.
transação" é recebida pelo
código de chamada.
Número de regras de rede Espaço de nomes 128

virtual e filtro IP
Limites do Site Recovery

Os seguintes limites aplicam-se à Recuperação do Sítio Azure.
IDEN T IF IC A DO R DE L IM IT E L IM IT E
Número de cofres por subscrição 500
Número de servidores por cofre Azure 250
Número de grupos de proteção por cofre Azure Sem limite
Número de planos de recuperação por cofre Azure Sem limite
Número de servidores por grupo de proteção Sem limite
Número de servidores por plano de recuperação 50
Limites de base de dados SQL

Para os limites da base de dados SQL, consulte os limites de recursos da Base de Dados SQL para bases de dados
únicas, limites de recursos da Base de Dados SQL para piscinas elásticas e bases de dados em piscinas,e limites de
recursos da Base de Dados SQL para instâncias geridas.
Limites do Armazém de Dados SQL

Para os limites do Armazém de Dados SQL, consulte os limites de recursos do Armazém de Dados SQL.
Limites de armazenamento
A tabela seguinte descreve os limites predefinidos para as contas de armazenamento de blob de uso geral da
Azure v1, v2, Blob e block blob. O limite de entrada refere-se a todos os dados enviados para uma conta de
armazenamento. O limite de saída refere-se a todos os dados recebidos de uma conta de armazenamento.
REC URSO L IM IT E
Número de contas de armazenamento por região por 250

subscrição, incluindo contas standard e de armazenamento
premium.
REC URSO L IM IT E
Capacidade máxima da conta de armazenamento 5 PiB 1
Número máximo de recipientes blob, blobs, ações de ficheiros, Sem limite

tabelas, filas, entidades ou mensagens por conta de
armazenamento
Taxa máxima de pedido1 por conta de armazenamento 20.000 pedidos por segundo
Entrada máxima1 por conta de armazenamento (EUA, regiões 10 Gbps

da Europa)
Entrada máxima1 por conta de armazenamento (regiões que 5 Gbps se ra-GRS/GRS estiver ativado, 10 Gbps para LRS/ZRS2
não os EUA e a Europa)
Saída máxima para as contas de armazenamento v2 e Blob 50 Gbps

(todas as regiões)
Saída máxima para contas de armazenamento v1 para fins 20 Gbps se ra-GRS/GRS estiver ativado, 30 Gbps para
gerais (regiões dos EUA) LRS/ZRS2
Saída máxima para as contas de armazenamento v1 para fins 10 Gbps se ra-GRS/GRS estiver ativado, 15 Gbps para
gerais (regiões não americanas) LRS/ZRS2
Número máximo de regras de rede virtuais por conta de 200

armazenamento
Número máximo de regras de endereço IP por conta de 200

armazenamento
1 As contas padrão de armazenamento Azure suportam limites de capacidade mais elevados e limites mais
elevados para a entrada por pedido. Para solicitar um aumento dos limites de conta, contacte o Suporte Azure.
2 Se a sua conta de armazenamento tiver acesso de leitura ativado com armazenamento geo-redundante (RA-GRS)
ou armazenamento de geo-zona redundante (RA-GZRS), então os alvos de saída para a localização secundária são
idênticos aos da localização primária. As opções de replicação do Armazenamento Azure incluem:
Armazenamento localmente redundante (LRS)
Armazenamento redundante em zona (ZRS)
Armazenamento georredundante (GRS)
Armazenamento georredundante com acesso de leitura (RA-GRS)
Armazenamento com redundância entre zonas (GZRS)
Armazenamento geozona-redundante de acesso de leitura (RA-GZRS)
3 Azure Data Lake Storage Gen2 é um conjunto de capacidades dedicadas à análise de big data, construídas no
armazenamento de Azure Blob.
NOTE
A Microsoft recomenda que utilize uma conta de armazenamento v2 para a maioria dos cenários. Pode facilmente atualizar
uma conta de armazenamento V1 ou Azure Blob para uma conta V2 para fins gerais, sem tempo de inatividade e sem
necessidade de copiar dados. Para obter mais informações, consulte upgrade para uma conta de armazenamento v2 para fins
gerais.
Se as necessidades da sua aplicação excederem os objetivos de escalabilidade de uma única conta de
armazenamento, pode construir a sua aplicação para utilizar várias contas de armazenamento. Em seguida, pode
dividir os seus objetos de dados através dessas contas de armazenamento. Para obter informações sobre os preços
de volume, consulte os preços de armazenamento Azure.
Todas as contas de armazenamento funcionam numa topologia de rede plana, independentemente de quando
foram criadas. Para obter mais informações sobre a arquitetura da rede plana Azure Storage e sobre a
escalabilidade, consulte o Microsoft Azure Storage: Um serviço de armazenamento de nuvem altamente disponível
com forte consistência.
Para obter mais informações sobre os limites das contas de armazenamento padrão, consulte os objetivos de
Escalaability para contas de armazenamento padrão.
Limites do fornecedor de recursos de armazenamento
Os seguintes limites aplicam-se apenas quando realiza operações de gestão utilizando o Gestor de Recursos Azure
com o Armazenamento Azure.
REC URSO L IM IT E
Operações de gestão de contas de armazenamento (ler) 800 por 5 minutos
Operações de gestão de conta de armazenamento (escrita) 10 por segundo / 1200 por hora
Operações de gestão de conta de armazenamento (lista) 100 por 5 minutos
Limites de armazenamento Azure Blob

REC URSO DEST IN O
Tamanho máximo do recipiente de bolha única O mesmo que a capacidade máxima da conta de
armazenamento
Número máximo de blocos em uma bolha de bloco ou bloco 50.000 blocos

de apêndice
Tamanho máximo de um bloco em uma bolha de bloco 100 MiB
Tamanho máximo de uma bolha de bloco 50.000 X 100 MiB (aproximadamente 4,75 TiB)
Tamanho máximo de um bloco em uma bolha de apêndice 4 MiB
Tamanho máximo de uma bolha de apêndice 50.000 x 4 MiB (aproximadamente 195 GiB)
Tamanho máximo de uma bolha de página 8 TiB
Número máximo de políticas de acesso armazenadas por 5

contentor blob
Taxa de pedido de destino para uma única bolha Até 500 pedidos por segundo
Entrada de destino para uma única página blob Até 60 MiB por segundo
Entrada de alvo para uma única bolha de bloco Até limites de entrada/saída da conta de armazenamento1
1 A entrada para uma única bolha depende de vários fatores, incluindo, mas não se limitando a: concurrency,
tamanho de pedido, nível de desempenho, velocidade de fonte para uploads e destino para downloads. Para tirar
partido das melhorias de desempenho das bolhas de bloco de alta perspância,carregue bolhas ou blocos maiores.
Especificamente, ligue para a operação Put Blob ou Put Block com uma bolha ou tamanho de bloco superior a 4
MiB para contas de armazenamento padrão. Para uma bolha de bloco premium ou para contas de armazenamento
de Data Lake Gen2, utilize um tamanho de bloco ou bolha superior a 256 KiB.
Limites de ficheiros Azure
Para obter mais informações sobre os limites dos Ficheiros Azure, consulte os objetivos de escalabilidade e
desempenho dos Ficheiros Azure.
REC URSO A Ç Õ ES DE F IC H EIRO S PA DRÃ O A Ç Õ ES DE F IC H EIRO P REM IUM
Tamanho mínimo de uma parte de Sem mínimos; pagar à medida que vai 100 GiB; provisionado
arquivo
Tamanho máximo de uma parte de 100 Tib*, 5 Tib 100 Tib

arquivo
Tamanho máximo de um ficheiro numa 1 TiB 1 TiB

partilha de ficheiros
Número máximo de ficheiros numa Sem limite Sem limite

partilha de ficheiros
IOPS máximopor ação 10.000 IOPS*, 1.000 IOPS 100.000 IOPS
Número máximo de políticas de acesso 5 5

armazenadas por partilha de ficheiros
Entrada de destino para uma única até 300 MiB/sec*, até 60 MiB/seg, Ver valores de entrada de partilha de
parte de ficheiro ficheiros premium e valores de egress
A máxima saída para uma única parte Ver a entrada padrão do alvo de Até 6.204 MiB/s
de ficheiro partilha de ficheiros
Ingresso máximo para uma única parte Ver a entrada padrão do alvo de Até 4.136 MiB/s
de ficheiro partilha de ficheiros
Cabos abertos máximos por ficheiro 2.000 pegas abertas 2.000 pegas abertas
Número máximo de instantâneos de 200 fotos de partilha 200 fotos de partilha

ações
Comprimento máximo do objeto 2.048 caracteres 2.048 caracteres

(diretórios e ficheiros)
Componente máximo do nome do 255 caracteres 255 caracteres

caminho (no caminho \A\B\C\D, cada
letra é um componente)
*O padrão nas ações de ficheiros padrão é 5 TiB, consulte Enable e crie grandes partilhas de ficheiros para os
detalhes sobre como aumentar a escala de ações de ficheiro padrão até 100 TiB.
Limites de Sincronização de Ficheiros Azure
REC URSO DEST IN O L IM IT E RÍGIDO
Serviços de Sincronização de 100 Serviços de Sincronização de Sim

Armazenamento por região Armazenamento
Grupos sincronizados por serviço de 200 grupos de sincronização Sim

sincronização de armazenamento
Servidores registados por Serviço de 99 servidores Sim

Sincronização de Armazenamento
Pontos finais da nuvem por grupo de 1 ponto final de nuvem Sim

sincronização
Pontos finais do servidor por grupo de 50 pontos finais do servidor Não

sincronização
Pontos finais do servidor por servidor 30 pontos finais do servidor Sim
Objetos do sistema de ficheiros 100 milhões de objetos Não

(diretórios e ficheiros) por grupo de
sincronização
Número máximo de objetos do sistema 5 milhões de objetos Sim

de ficheiros (diretórios e ficheiros) num
diretório
Tamanho máximo do descritor de 64 KiB Sim

segurança de objetos (diretórios e
ficheiros)
Tamanho dos ficheiros 100 GiB Não
Tamanho mínimo do ficheiro para um V9: Baseado no tamanho do cluster do Sim

ficheiro a ser nivelado sistema de ficheiros (tamanho do
cluster do sistema de ficheiros duplos).
Por exemplo, se o tamanho do cluster
do sistema de ficheiros for de 4kb, o
tamanho mínimo do ficheiro será de
8kb.
V8 e mais velho: 64 KiB
NOTE
Um ponto final Azure File Sync pode escalar até ao tamanho de uma partilha de ficheiros Azure. Se o limite de tamanho da
ação do ficheiro Azure for atingido, a sincronização não poderá funcionar.
Limites de armazenamento da fila Azure

REC URSO DEST IN O
Tamanho máximo de uma única fila 500 TiB
Tamanho máximo de uma mensagem em uma fila 64 KiB

REC URSO DEST IN O
Número máximo de políticas de acesso armazenadas por fila 5
Taxa máxima de pedidos por conta de armazenamento 20.000 mensagens por segundo, o que pressupõe um
tamanho de mensagem 1-KiB
Entrada de destino para uma única fila (mensagens 1-KiB) Até 2.000 mensagens por segundo
Limites de armazenamento da mesa Azure

A tabela que se segue descreve a capacidade, a escalabilidade e os objetivos de desempenho para o
armazenamento de mesas.
REC URSO DEST IN O
Número de tabelas numa conta de armazenamento Azure Limitado apenas pela capacidade da conta de armazenamento
Número de divisórias em uma mesa Limitado apenas pela capacidade da conta de armazenamento
Número de entidades em partição Limitado apenas pela capacidade da conta de armazenamento
Tamanho máximo de uma única mesa 500 TiB
Tamanho máximo de uma única entidade, incluindo todos os 1 MiB

valores patrimoniais
Número máximo de imóveis numa entidade de mesa 255 (incluindo as três propriedades do sistema, Par titionKey,
RowKey , e Timestamp)
Tamanho total máximo de uma propriedade individual numa Varia por tipo de propriedade. Para mais informações, consulte
entidade Os Tipos de Propriedade na Compreensão do Modelode
Dados do Serviço de Tabela .
Tamanho da Chave da Par tição Uma corda até 1 KiB em tamanho
Tamanho da Chave Row Uma corda até 1 KiB em tamanho
Tamanho de uma transação de grupo de entidades Uma transação pode incluir no máximo 100 entidades e a
carga útil deve ter menos de 4 MiB em tamanho. Uma
transação de grupo de entidades pode incluir uma atualização
para uma entidade apenas uma vez.
Número máximo de políticas de acesso armazenadas por 5

tabela
Taxa máxima de pedidos por conta de armazenamento 20.000 transações por segundo, o que pressupõe uma
dimensão de 1-KiB
Entrada de destino para uma única partilha de tabela (1 KiB- Até 2.000 entidades por segundo
entidades)
Limites de disco de máquina virtual

Pode anexar vários discos de dados a uma máquina virtual Azure. Com base nos alvos de escalabilidade e
desempenho dos discos de dados de um VM, pode determinar o número e o tipo de disco que necessita para
satisfazer os seus requisitos de desempenho e capacidade.
IMPORTANT
Para um desempenho ótimo, limite o número de discos altamente utilizados ligados à máquina virtual para evitar uma
possível aceleração. Se todos os discos ligados não forem altamente utilizados ao mesmo tempo, a máquina virtual pode
suportar um maior número de discos.
Para discos geridos pelo Azure:

O quadro que se segue ilustra o padrão e os limites máximos do número de recursos por região por subscrição.
Não existe limite para o número de Discos Geridos, instantâneos e imagens por grupo de recursos.
REC URSO L IM IT E
Discos geridos por padrão 50 000
Discos geridos por SSD padrão 50 000
Discos geridos premium 50 000
Standard_LRS instantâneos 50 000
Standard_ZRS instantâneos 50 000
Imagem gerida 50 000
Para contas de armazenamento standard: Uma conta de armazenamento Standard tem uma taxa total
máxima de pedido de 20.000 IOPS. O total de IOPS em todos os seus discos de máquina virtual numa conta
de armazenamento Standard não deve exceder este limite.
Pode calcular aproximadamente o número de discos altamente utilizados suportados por uma única conta
de armazenamento Standard com base no limite da taxa de pedido. Por exemplo, para um VM de nível
básico, o número máximo de discos altamente utilizados é de cerca de 66, que é de 20.000/300 IOPS por
disco. O número máximo de discos altamente utilizados para um VM de nível Standard é de cerca de 40, que
é de 20.000/500 IOPS por disco.
Para contas de armazenamento Premium: Uma conta de armazenamento Premium tem uma taxa
máxima de produção total de 50 Gbps. O débito total em todos os discos da VM não deve exceder este
limite.
Para obter mais informações, consulte os tamanhos da máquina virtual.
Discos de máquinas virtuais geridos
Discos geridos por HDD padrão
T IP O
DE
DISC O
STA N
DA RD S4 S6 S10 S15 S20 S30 S40 S50 S60 S70 S80
Taman 32 64 128 256 512 1,024 2048 4,096 8,192 16 38 32

ho do 4 767
disco
em
GiB
IOPs Até Até Até Até Até Até Até Até Até Até Até
por 500 500 500 500 500 500 500 500 1.300 2.000 2.000
disco
Débit Até Até Até Até Até Até Até Até 60 Até Até Até
o por 60 60 60 60 60 60 60 MB/se 300 500 500
disco MB/se MB/se MB/se MB/se MB/se MB/se MB/se g MB/se MB/se MB/se
g g g g g g g g g g
Discos geridos por SSD padrão
TA
MA
NH
OS
SSD
PA D
RÃ
O E1 E2 E3 E4 E6 E10 E15 E20 E30 E40 E50 E60 E70 E80
Tam 4 8 16 32 64 128 256 512 1,02 204 4,09 8,19 16 32

anh 4 8 6 2 384 767
o
do
disc
o
em
GiB
IOP Até Até Até Até Até Até Até Até Até Até Até Até Até Até
s 500 500 500 500 500 500 500 500 500 500 500 2.00 4.00 6.00
por 0 0 0
disc
o
Déb Até Até Até Até Até Até Até Até Até Até Até Até Até Até
ito 60 60 60 60 60 60 60 60 60 60 60 400 600 750
por MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/
disc seg seg seg seg seg seg seg seg seg seg seg seg seg seg
o
Discos geridos premium SSD: limites por disco

TA
MA
NH
OS
P RE
M IU
M
SSD
P1 P2 P3 P4 P6 P 10 P 15 P 20 P 30 P 40 P 50 P 60 P 70 P 80
Tam 4 8 16 32 64 128 256 512 1,02 204 4,09 8,19 16 32

anh 4 8 6 2 384 767
o
do
disc
o
em
GiB
OPS 120 120 120 120 240 500 110 230 500 7.50 7.50 16 18 20
pro 0 0 0 0 0 000 000 000
viso
s
por
disc
o
Pro 25 25 25 25 50 100 125 150 200 250 250 500 750 900
duç MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/
ão a seg seg seg seg seg seg seg seg seg seg seg seg seg seg
pro
visi
ona
da
por
disc
o
IOP 350 350 350 350 350 350 350 350

S de 0 0 0 0 0 0 0 0
expl
osã
o
de
max
por
disc
o
Pro 170 170 170 170 170 170 170 170

duç MB/ MB/ MB/ MB/ MB/ MB/ MB/ MB/
ão seg seg seg seg seg seg seg seg
de
rutu
ra
de
Max
por
disc
o
TA
MA
NH
OS
P RE
M IU
M
SSD
P1 P2 P3 P4 P6 P 10 P 15 P 20 P 30 P 40 P 50 P 60 P 70 P 80
Dur 30 30 30 30 30 30 30 30
açã min min min min min min min min
o
máx
ima
da
expl
osã
o
Eleg Não Não Não Não Não Não Não Não Sim, Sim, Sim, Sim, Sim, Sim,
ível até até até até até até
par um um um um um um
a ano. ano. ano. ano. ano. ano.
rese
rva
Discos geridos premium SSD: limites Per-VM
REC URSO L IM IT E
IOPS máximos por VM 80.000 IOPS com GS5 VM
Potência máxima por VM 2.000 MB/s com GS5 VM
Discos de máquinas virtuais não geridos

Discos de máquinas vir tuais não geridos padrão: limites por disco
VM N ÍVEL VM DE N ÍVEL B Á SIC O VM DE N ÍVEL PA DRÃ O
Tamanho do disco 4.095 GB 4.095 GB
IOPS máximo de 8-KB por disco 300 500

persistente
Número máximo de discos que 66 40

executam o IOPS máximo
Discos de máquinas vir tuais não geridos premium: limites por conta
REC URSO L IM IT E
Capacidade total do disco por conta 35 TB
Capacidade total do instantâneo por conta 10 TB
Largura de banda máxima por conta (ingress + egress)1 <=50 Gbps
1
1Ingress refere-se a todos os dados dos pedidos enviados para uma conta de armazenamento. A Egress refere-se a
todos os dados de respostas recebidas de uma conta de armazenamento.

Discos de máquinas vir tuais não geridos premium: limites por disco
T IP O DE DISC O
DE
A RM A Z EN A M EN
TO P REM IUM P 10 P 20 P 30 P 40 P 50
Tamanho do 128 GiB 512 GiB 1.024 GiB (1 TB) 2.048 GiB (2 TB) 4.095 GiB (4 TB)
disco
IOPS máximopor 500 2300 5000 7.500 7.500

disco
Potência máxima 100 MB/seg 150 MB/seg 200 MB/seg 250 MB/seg 250 MB/seg
por disco
Número máximo 280 70 35 17 8

de discos por
conta de
armazenamento
Discos de máquinas vir tuais não geridos premium: limites Per-VM
REC URSO L IM IT E
IOPS máximos por VM 80.000 IOPS com GS5 VM
Potência máxima por VM 2.000 MB/seg com GS5 VM
Limites do Sistema StorSimple

IDEN T IF IC A DO R DE L IM IT E L IM IT E C O M EN TÁ RIO S
Número máximo de credenciais de 64

conta de armazenamento
Número máximo de contentores de 64

volume
Número máximo de volumes 255
Número máximo de horários por 168 Um horário para cada hora, todos os
modelo de largura de banda dias da semana.
Tamanho máximo de um volume 64 TB para StorSimple 8100 e StorSimple 8100 e StorSimple 8600 são
hierárquico em dispositivos físicos StorSimple 8600 dispositivos físicos.
Tamanho máximo de um volume 30 TB para StorSimple 8010 StorSimple 8010 e StorSimple 8020 são
hierárquico em dispositivos virtuais em 64 TB para StorSimple 8020 dispositivos virtuais em Azure que
Azure utilizam armazenamento Standard e
armazenamento Premium,
respectivamente.
Tamanho máximo de um volume fixado 9 TB para StorSimple 8100 StorSimple 8100 e StorSimple 8600 são
localmente em dispositivos físicos 24 TB para StorSimple 8600 dispositivos físicos.
Número máximo de ligações iSCSI 512
Número máximo de ligações iSCSI de 512

iniciadores
Número máximo de registos de 64

controlo de acesso por dispositivo
Número máximo de volumes por 24

política de backup
Número máximo de backups retidos 64

por política de backup
Número máximo de horários por 10

política de backup
Número máximo de instantâneos de 256 Esta quantidade inclui instantâneos

qualquer tipo que possa ser retido por locais e imagens em nuvem.
volume
Número máximo de instantâneos que 10,000

podem estar presentes em qualquer
dispositivo
Número máximo de volumes que 16 Se houver mais de 16 volumes,

podem ser processados paralelamente são processados
para cópia de segurança, restauro ou sequencialmente à medida que
clone as ranhuras de processamento
ficam disponíveis.
Novas cópias de segurança de
um volume clonado ou de um
volume de camadas restaurado
não podem ocorrer até que a
operação esteja terminada. Para
um volume local, as cópias de
segurança são permitidas após o
volume estar on-line.
Restaurar e clonar tempo de <2 minutos O volume é disponibilizado no

recuperação para volumes hierárquicos prazo de 2 minutos após uma
operação de restauro ou clone,
independentemente do
tamanho do volume.
O desempenho do volume pode
inicialmente ser mais lento do
que o normal, uma vez que a
maioria dos dados e metadados
ainda residem na nuvem. O
desempenho pode aumentar à
medida que os dados fluem da
nuvem para o dispositivo
StorSimple.
O tempo total para descarregar
metadados depende do
tamanho do volume atribuído.
Os metadados são
automaticamente introduzidos
no dispositivo em segundo
plano à taxa de 5 minutos por
Tuberculose dos dados de
volume atribuídos. Esta taxa
pode ser afetada pela largura de
banda da Internet para a nuvem.
A operação de restauro ou clone
fica completa quando todos os
metadados estão no dispositivo.
As operações de backup não
podem ser realizadas até que a
operação de restauro ou clone
esteja totalmente completa.
Restaurar o tempo de recuperação para <2 minutos O volume é disponibilizado no

volumes fixados localmente prazo de 2 minutos após a
operação de restauro,
independentemente do
tamanho do volume.
O desempenho do volume pode
inicialmente ser mais lento do
que o normal, uma vez que a
maioria dos dados e metadados
ainda residem na nuvem. O
desempenho pode aumentar à
medida que os dados fluem da
nuvem para o dispositivo
StorSimple.
O tempo total para descarregar
metadados depende do
tamanho do volume atribuído.
Os metadados são
automaticamente introduzidos
no dispositivo em segundo
plano à taxa de 5 minutos por
Tuberculose dos dados de
volume atribuídos. Esta taxa
pode ser afetada pela largura de
banda da Internet para a nuvem.
Ao contrário dos volumes
hierárquicos, se houver volumes
fixados localmente, os dados de
volume também são
descarregados localmente no
dispositivo. A operação de
restauro fica completa quando
todos os dados de volume
foram trazidos para o
dispositivo.
As operações de restauro
podem ser longas e o tempo
total para completar a
restauração dependerá da
dimensão do volume local
previsto, da largura de banda da
Internet e dos dados existentes
no dispositivo. As operações de
backup no volume fixado
localmente são permitidas
enquanto a operação de
restauro está em curso.
Disponibilidade de restauração fina Última falha
A maior leitura/escrita do cliente, 920/720 MB/seg com uma única Até duas vezes com MPIO e duas
quando servida a partir do nível SSD* interface de rede Ethernet de 10 interfaces de rede.
gigabits
A maior leitura/escrita do cliente, 120/250 MB/seg

quando servida a partir do nível HDD*
A entrada máxima de leitura/escrita do 11/41 MB/seg A leitura da produção depende da

cliente, quando servida a partir do nível geração e manutenção da profundidade
de nuvem* suficiente da fila de I/S.
*a potência máxima por tipo De/S foi medida com 100% de leitura e 100% de cenários de escrita. A produção real
pode ser mais baixa e depende da mistura de I/S e das condições de rede.
Limites de Análise de Fluxo

Número máximo de unidades de 500 Para solicitar um aumento das unidades

streaming por subscrição por região de streaming para a sua subscrição para
além de 500, contacte o Microsoft
Support.
Número máximo de entradas por tarefa 60 Há um limite de 60 entradas por

trabalho da Azure Stream Analytics.
Número máximo de saídas por tarefa 60 Há um limite de 60 saídas por trabalho

da Stream Analytics.
Número máximo de funções por tarefa 60 Há um limite de 60 funções por

trabalho de Stream Analytics.
Número máximo de unidades de 192 Há um limite de 192 unidades de

streaming por trabalho streaming por trabalho de Stream
Analytics.
Número máximo de tarefas por região 1500 Cada subscrição pode ter até 1.500
postos de trabalho por região
geográfica.
MB do blob dos dados de referência 300 As bolhas de dados de referência não

podem ser maiores do que 300 MB
cada.
Número máximo de caracteres numa 512000 Há um limite duro de caracteres de

consulta 512k numa consulta de trabalho do
Azure Stream Analytics.
Limites de máquinas virtuais

Limites de máquinas virtuais
REC URSO L IM IT E
Máquinas virtuais por serviço de nuvem1 50
Pontos finais de entrada por serviço na nuvem2 150
1 As máquinas virtuais criadas utilizando o modelo de implantação clássico em

vez do Azure Resource Manager
são automaticamente armazenadas num serviço na nuvem. Pode adicionar mais máquinas virtuais a esse serviço
de nuvem para equilibrar e disponibilidade de carga.
2 Os pontos finais de entrada permitem comunicações a uma máquina virtual de fora do serviço de nuvem da
máquina virtual. As máquinas virtuais no mesmo serviço de nuvem ou rede virtual podem comunicar-se
automaticamente entre si. Para mais informações, consulte Como configurar pontos finais para uma máquina
virtual.
Limites de máquinas virtuais - Gestor de Recursos Azure
Os seguintes limites aplicam-se quando utiliza grupos de recursos Azure Resource Manager e Azure.
REC URSO L IM IT E
VMs por subscrição 25.0001 por região.
Total de núcleos de VM por subscrição 201 por região. Suporte de contato para aumentar o limite.
Núcleos totais de VM Azure Spot por subscrição 201 por região. Suporte de contato para aumentar o limite.
VM por série, tais como Dv2 e F, núcleos por subscrição 201 por região. Suporte de contato para aumentar o limite.
Conjuntos de disponibilidade por subscrição 2.500 por região.
Máquinas virtuais por conjunto de disponibilidade 200
Certificados por subscrição Ilimitado2
1 Os limites padrão variam por tipo de categoria de oferta, como Free Trial e Pay-As-You-Go, e por séries, tais como
Dv2, F e G. Por exemplo, o padrão para subscrições do Acordo Empresarial é de 350.
2 Com o Gestor de Recursos Azure, os certificados são armazenados no Cofre de Chaves Azure. O número de
certificados é ilimitado para uma subscrição. Há um limite de 1-MB de certificados por implantação, que consiste
num único VM ou num conjunto de disponibilidade.
NOTE
Os núcleos de máquinas virtuais têm um limite total regional. Eles também têm um limite para séries regionais por tamanho,
como Dv2 e F. Estes limites são aplicados separadamente. Por exemplo, considere uma subscrição com um limite total de
núcleos de VM na região E.U.A. Leste de 30, um limite de núcleos de série A de 30 e um limite de núcleos de série D de 30.
Esta subscrição pode implementar 30 VMs A1, ou 30 VMs D1, ou uma combinação dos dois para não exceder um total de
30 núcleos. Um exemplo de uma combinação é 10 VMs A1 e 20 VMs D1.
Limites da Galeria de Imagens Partilhadas

Existem limites, por subscrição, para a implantação de recursos utilizando galerias de imagem partilhadas:
100 galerias de imagem partilhadas, por subscrição, por região
1.000 definições de imagem, por subscrição, por região
10.000 versões de imagem, por subscrição, por região
Escala de máquina virtual define limites

REC URSO L IM IT E
Número máximo de VMs num conjunto de dimensionamento 1,000

REC URSO L IM IT E
Número máximo de VMs com base numa imagem VM 600

personalizada num conjunto de escala
Número máximo de conjuntos de dimensionamento numa 2.500

região
Ver também
Compreender os limites e aumentos do Azure
Tamanhos de serviço de máquina virtual e nuvem para Azure
Tamanhos para Serviços cloud Azure
Regras de nomenclatura e restrições para recursos do Azure
Melhores Práticas do Serviço de Aplicações do Azure
Este artigo resume as melhores práticas para a utilização do Serviço de Aplicações Azure.
Colocalização
Quando os recursos do Azure compõem uma solução como uma aplicação web e uma base de dados estão localizadas em diferentes regiões, pode ter os seguintes efeitos:
Maior latência na comunicação entre recursos
Encargos monetários para a transferência de dados de saída transporam regiões, tal como se nota na página de preços do Azure.
A colocalização na mesma região é o melhor para os recursos do Azure que compõem uma solução como uma aplicação web e uma conta de base de dados ou
armazenamento usada para conter conteúdo ou dados. Ao criar recursos, certifique-se de que estão na mesma região de Azure, a menos que tenha razões específicas para
não estar. Pode mover uma aplicação do App Service para a mesma região que a sua base de dados utilizando a funcionalidade de clonagem do Serviço de Aplicações
atualmente disponível para aplicações premium app Service Plan.
Quando as aplicações consomem mais memória do que o esperado

Quando notar que uma aplicação consome mais memória do que o esperado, como indicado através de recomendações de monitorização ou de serviço, considere a
funcionalidade de Cura Automática do Serviço de Aplicações. Uma das opções para a funcionalidade de Cura Automática é tomar ações personalizadas com base num limiar
de memória. As ações abrangem o espectro desde notificações de e-mail até à investigação através de despejo de memória até à mitigação no local, reciclando o processo do
trabalhador. A cicatrização automática pode ser configurada através de web.config e através de uma interface de utilizador amigável, como descrito neste post de blog para a
extensão do site de suporte ao serviço de aplicações.
Quando as aplicações consomem mais CPU do que o esperado

Quando notar que uma aplicação consome mais CPU do que o esperado ou experimenta picos de CPU repetidos, conforme indicado através de recomendações de
monitorização ou de serviço, considere escalonar ou escalonar o plano de Serviço de Aplicações. Se a sua aplicação for audatória, a escala é a única opção, enquanto que se a
sua aplicação for apátrida, a escala ção dá-lhe mais flexibilidade e maior potencial de escala.
Para mais informações sobre aplicações "apátridas" vs "apátridas" pode ver este vídeo: Planejando uma aplicação de vários níveis escalável no Serviço de Aplicações Azure.
Para obter mais informações sobre opções de escalae e autoscalcificação do Serviço de Aplicações, consulte Scale a Web App no Serviço de Aplicações Azure.
Quando os recursos da tomada estão esgotados

Uma razão comum para esgotar as ligações TCP de saída é a utilização de bibliotecas de clientes, que não são implementadas para reutilizar ligações TCP, ou quando não é
utilizado um protocolo de nível superior como http - Keep-Alive. Reveja a documentação de cada uma das bibliotecas referenciadas pelas aplicações no seu Plano de Serviço
de Aplicações para garantir que são configuradas ou acedidas no seu código para uma reutilização eficiente das ligações de saída. Siga também a orientação da
documentação da biblioteca para a criação e libertação ou limpeza adequadas para evitar fugas de ligações. Embora tais investigações de bibliotecas de clientes estejam em
curso, o impacto pode ser atenuado através da escala para vários casos.
Node.js e pedidos de http de saída
Ao trabalhar com o Node.js e muitos pedidos de http de saída, lidar com http - Keep-Alive é importante. Pode usar o pacote agentkeepalive npm para facilitar o seu código.
Manuseie sempre a http resposta, mesmo que não faça nada no manipulador. Se não manusear corretamente a resposta, a sua aplicação fica presa eventualmente porque
não há mais tomadas disponíveis.
Por exemplo, quando http se https trabalha com o ou o pacote:
const request = https.request(options, function(response) {

response.on('data', function() { /* do nothing */ });
});
Se estiver a executar o Serviço de Aplicações no Linux numa máquina com vários núcleos, outra melhor prática é usar o PM2 para iniciar vários processos nonómetros para
executar a sua aplicação. Pode fazê-lo especificando um comando de arranque no seu recipiente.
Por exemplo, para iniciar quatro instâncias:
pm2 start /home/site/wwwroot/app.js --no-daemon -i 4
Quando a cópia de segurança da sua aplicação começa a falhar

As duas razões mais comuns para a falha na cópia de segurança da aplicação são: configurações de armazenamento inválidas e configuração de bases de dados inválidas.
Estas falhas normalmente acontecem quando há alterações nos recursos de armazenamento ou base de dados, ou alterações na forma de aceder a esses recursos (por
exemplo, credenciais atualizadas para a base de dados selecionada sintetizadas nas definições de backup). As cópias de segurança normalmente funcionam num horário e
exigem o acesso ao armazenamento (para a colocação dos ficheiros de reserva) e bases de dados (para copiar e ler conteúdos a incluir na cópia). O resultado de não aceder a
nenhum destes recursos seria uma falha consistente de backup.
Quando as falhas de backup acontecerem, reveja os resultados mais recentes para perceber que tipo de falha está a acontecer. Para falhas de acesso ao armazenamento,
reveja e atualize as definições de armazenamento utilizadas na configuração de backup. Para falhas de acesso à base de dados, reveja e atualize as cordas das suas ligações
como parte das definições da aplicação; em seguida, proceda à atualização da sua configuração de backup para incluir corretamente as bases de dados necessárias. Para obter
mais informações sobre cópias de segurança de apps, consulte a backup de uma aplicação web no Azure App Service.
Quando novas aplicações noNó.js são implementadas para o Serviço de Aplicações Azure
A configuração padrão do Serviço de Aplicações Azure para aplicações Node.js destina-se a melhor atender às necessidades das aplicações mais comuns. Se a configuração
da sua app Node.js beneficiar de afinação personalizada para melhorar o desempenho ou otimizar o uso de recursos de recursos cpu/memória/rede, consulte as melhores
práticas e guia de resolução de problemas para aplicaçõesde nó no Serviço de Aplicações Azure . Este artigo descreve as definições de iisnode que poderá ter de configurar
para a sua aplicação Node.js, descreve os vários cenários ou problemas que a sua aplicação pode estar a enfrentar e mostra como lidar com estes problemas.
Passos Seguintes
Para obter mais informações sobre as melhores práticas, visite o App Service Diagnostics para descobrir as melhores práticas atol específicas do seu recurso.
Navegue para a sua Web App no portal Azure.
Clique em Diagnosticar e resolver problemas na navegação à esquerda, o que abre diagnósticos de serviço de aplicações.
Escolha o azulejo da página inicial das Melhores Práticas.
Clique em Boas Práticas para Disponibilidade & Desempenho ou Boas Práticas para Uma Configuração Ideal para ver o estado atual da sua aplicação no que
diz respeito a estas boas práticas.
Também pode utilizar este link para abrir diretamente os
https://ms.portal.azure.com/?
websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Micr
Diagnósticos do Serviço de Aplicações para o seu recurso: .
Resolução de erros intermitentes de ligação de saída
no Serviço de Aplicações Azure
Este artigo ajuda-o a resolver erros de ligação intermitentes e problemas de desempenho relacionados no Serviço
de Aplicações Azure. Este tópico fornecerá mais informações sobre e metodologias de resolução de problemas
para, esgotamento das portas de tradução de rede de endereços de origem (SNAT). Se necessitar de mais ajuda em
qualquer ponto deste artigo, contacte os especialistas do Azure no MSDN Azure e nos fóruns stack Overflow. Em
alternativa, apresente um incidente de apoio ao Azure. Vá ao site de suporte do Azure e selecione Obter Supor te .
Sintomas
As aplicações e funções hospedadas no serviço Azure App podem apresentar um ou mais dos seguintes sintomas:
Tempos de resposta lentos em todos ou alguns dos casos de um plano de serviço.
Erros intermitentes 5xx ou Bad Gateway
Mensagens de erro de timeout
Não podia ligar-se a pontos finais externos (como SQLDB, Service Fabric, outros serviços de Aplicação, etc.)
Causa
Uma das principais causas destes sintomas é que a instância de aplicação não é capaz de abrir uma nova ligação ao
ponto final externo porque atingiu um dos seguintes limites:
Ligações TCP: Existe um limite para o número de ligações de saída que podem ser feitas. Isto está associado ao
tamanho do trabalhador utilizado.
Portas SNAT: Conforme discutido nas ligações de saída em Azure,o Azure utiliza a tradução de endereços de
rede fonte (SNAT) e um Balancer de Carga (não exposto aos clientes) para comunicar com pontos finais fora do
Azure no espaço público de endereços IP. Cada instância no serviço Azure App é inicialmente dada um número
pré-atribuído de 128 portas SNAT. Este limite afeta as ligações de abertura à mesma combinação de hospedeiro
e porta. Se a sua aplicação criar ligações a uma mistura de endereços e combinações de portas, não utilizará as
portas SNAT. As portas SNAT são usadas quando tem chamadas repetidas para o mesmo endereço e
combinação de porta. Uma vez libertada uma porta, a porta está disponível para reutilização conforme
necessário. O equilibrador de carga da Rede Azure recupera a porta SNAT das ligações fechadas apenas depois
de esperar 4 minutos.
Quando as aplicações ou funções abrem rapidamente uma nova ligação, podem esgotar rapidamente a sua quota
pré-atribuída das 128 portas. São então bloqueados até que uma nova porta SNAT fique disponível, quer através
da atribuição dinâmica de portas SNAT adicionais, quer através da reutilização de uma porta SNAT recuperada.
Aplicações ou funções bloqueadas devido a esta incapacidade de criar novas ligações começarão a experimentar
uma ou mais das questões descritas na secção sintomas deste artigo.
Evitando o problema
Evitar o problema da porta SNAT significa evitar a criação de novas ligações repetidamente ao mesmo hospedeiro
e porto.
As estratégias gerais para atenuar a exaustão portuária sNAT são discutidas na secção de resolução de problemas
das ligações de saída da documentação Azure. Destas estratégias, aplicam-se as seguintes aplicações e funções
hospedadas no serviço Azure App.
Modificar a aplicação para utilizar o pooling de ligação
Para juntar ligações HTTP, reveja as ligações Pool HTTP com httpClientFactory.
Para obter informações sobre o pooling de ligação do Servidor SQL, reveja o Pooling de Ligação do Servidor
SQL (ADO.NET).
Para implementar o agrupamento com aplicações-quadro da entidade, reveja o agrupamento DbContext.
Aqui está uma coleção de links para implementar o pool de Ligação por diferentes soluçãostack.
Nó
Por defeito, as ligações para o NodeJS não são mantidas vivas. Abaixo estão as bases de dados e pacotes populares
para o agrupamento de ligações que contêm exemplos de como implementá-los.
MySQL
MongoDB
PostgreSQL
SQL Server
HTTP Manter-se vivo
agentemantervivo
Node.js v13.9.0 Documentação
Java
Abaixo estão as bibliotecas populares utilizadas para o agrupamento de ligações JDBC que contêm exemplos de
como implementá-las: JDBC Connection Pooling.
Tomcat 8
C3p0
HikariCP
Apache DBCP
HTTP Connection Pooling
Gestão de Conexão Apache
Class PoolingHttpClientConnectionManager
PHP
Embora a PHP não suporte o pool de ligação, pode tentar utilizar ligações persistentes de base de dados ao seu
servidor back-end.
Servidor MySQL
Ligações MySQLi para versões mais recentes
mysql_pconnect versões mais antigas de PHP
Outras Fontes de Dados
Gestão de Ligações PHP
Python
MySQL
MongoDB
PostgreSQL
Servidor SQL (NOTA: SQLAlchemy pode ser usado com outras bases de dados além do Servidor MicrosoftSQL)
HTTP Keep-alive(Keep-Alive é automático ao utilizar sessões de sessões de objetos de sessão).
Para outros ambientes, fornecedor de revisão ou documentos específicos do condutor para a implementação do
agrupamento de ligações nas suas aplicações.
Modificar a aplicação para reutilizar ligações
Para obter indicações adicionais e exemplos sobre a gestão de ligações em funções Azure, reveja gerir as
ligações em Funções Azure.
Modificar a aplicação para usar uma lógica de retry menos agressiva
Para obter orientações e exemplos adicionais, reveja o padrão de retry.
Use vidas de manutenção para repor o tempo de saída inativo
Para implementar as vidas de keepalives para aplicações Node.js, reveja a minha aplicação de nó está a fazer
chamadas de saída excessivas.
Orientação adicional específica ao Serviço de Aplicações:
Um teste de carga deve simular dados do mundo real numa velocidade constante de alimentação. Testar
aplicações e funções sob o stress do mundo real pode identificar e resolver problemas de exaustão da porta
SNAT com antecedência.
Certifique-se de que os serviços de back-end podem devolver respostas rapidamente. Para problemas de
resolução de problemas de desempenho com base de dados Azure SQL, reveja os problemas de desempenho
da Troubleshoot Azure SQL Database com Insights Inteligentes.
Esforce o plano do Serviço de Aplicações para mais casos. Para obter mais informações sobre escala, consulte
Scale uma aplicação no Azure App Service. Cada instância de trabalhador num plano de serviço de aplicações é
atribuída a várias portas SNAT. Se espalhar o seu uso por mais casos, poderá obter o uso da porta SNAT por
exemplo abaixo do limite recomendado de 100 ligações de saída, por ponto final remoto único.
Considere mudar-se para o App Service Environment (ASE),onde lhe é atribuído um único endereço IP de saída,
e os limites para ligações e portas SNAT são muito mais elevados.
Evitar os limites de TCP de saída é mais fácil de resolver, uma vez que os limites são definidos pelo tamanho do seu
trabalhador. Pode ver os limites em Limites Numéricos Sandbox Cross VM - Ligações TCP
N ÍVEL ISO L A DO
N O M E- L IM IT E DESC RIÇ Ã O P EQ UEN O ( A 1) M ÉDIO ( A 2) GRA N DE ( A 3) ( A SE)
Ligações Número de 1920 3968 8064 16 000

ligações em toda
a VM
Para evitar limites de TCP de saída, pode aumentar o tamanho dos seus trabalhadores ou escalar horizontalmente.
Conhecer os dois tipos de limites de ligação de saída e o que a sua aplicação faz, deve facilitar a resolução de
problemas. Se souber que a sua aplicação faz muitas chamadas para a mesma conta de armazenamento, pode
suspeitar de um limite de SNAT. Se a sua aplicação criar muitas chamadas para pontos finais por toda a internet,
suspeita-se que está a atingir o limite de VM.
Se desconhece o comportamento da aplicação o suficiente para determinar rapidamente a causa, existem algumas
ferramentas e técnicas disponíveis no Serviço de Aplicações para ajudar nessa determinação.
Encontre informações sobre atribuição de portas SNAT
Você pode usar diagnósticos de serviço de aplicativos para encontrar informações de atribuição de portas SNAT, e
observar a métrica de atribuição de portas SNAT de um site de Serviço de Aplicações. Para encontrar informações
sobre a atribuição de portas SNAT, siga os seguintes passos:
1. Para aceder aos diagnósticos do Serviço de Aplicações, navegue para a sua aplicação web do App Service ou
para o App Service Environment no portal Azure. Na navegação à esquerda, selecione Diagnosticar e
resolver problemas .
2. Selecione Categoria de Disponibilidade e Desempenho
3. Selecione azulejos de exaustão por porta SNAT na lista de azulejos disponíveis na categoria. A prática é mantê-
lo abaixo de 128. Se precisar, ainda pode abrir um bilhete de apoio e o engenheiro de apoio receberá a métrica
do back-end para si.
Note que, uma vez que o uso da porta SNAT não está disponível como métrica, não é possível nem
automaticamente com base na utilização da porta SNAT, nem configurar a escala automática com base na métrica
de atribuição de portas SNAT.
Ligações TCP e Portas SNAT
As ligações TCP e as portas SNAT não estão diretamente relacionadas. Um detetor de utilização de ligações TCP
está incluído na lâmina de diagnóstico e resolução de problemas de qualquer site do Serviço de Aplicações.
Procure a frase "ligações TCP" para encontrá-la.
As portas SNAT são utilizadas apenas para fluxos de rede externos, enquanto as ligações tcp totais incluem
ligações de retorno local.
Uma porta SNAT pode ser partilhada por diferentes fluxos, se os fluxos forem diferentes em protocolo,
endereço IP ou porta. A métrica de Ligações TCP conta todas as ligações TCP.
O limite de ligações TCP acontece ao nível da instância do trabalhador. O equilíbrio de carga de saída da Rede
Azure não utiliza a métrica de ligações TCP para a limitação da porta SNAT.
Os limites de ligações TCP são descritos nos limites numéricos Sandbox Cross VM - Ligações TCP
N ÍVEL ISO L A DO
N O M E- L IM IT E DESC RIÇ Ã O P EQ UEN O ( A 1) M ÉDIO ( A 2) GRA N DE ( A 3) ( A SE)
Ligações Número de 1920 3968 8064 16 000

ligações em toda
a VM
WebJobs e ligações de base de dados

Se as portas SNAT estiverem esgotadas, onde o WebJobs não conseguir ligar-se à base de dados Azure SQL, não
existe uma métrica que demonstre quantas ligações são abertas por cada processo de aplicação web individual.
Para encontrar o WebJob problemático, mova vários WebJobs para outro plano de Serviço de Aplicações para ver
se a situação melhora, ou se um problema permanece num dos planos. Repita o processo até encontrar o WebJob
problemático.
Usando portas SNAT mais cedo
Não é possível alterar quaisquer configurações do Azure para libertar as portas SNAT usadas mais cedo, uma vez
que todas as portas SNAT serão libertadas de acordo com as condições abaixo e o comportamento é por design.
Se um servidor ou cliente enviar finack, a porta SNAT será libertada após 240 segundos.
Se for visto um RST, a porta SNAT será libertada após 15 segundos.
Se o tempo de paragem inativa tiver sido atingido, a porta é libertada.
Informações adicionais
SNAT com Serviço de Aplicações
Problemas de desempenho lento de aplicações no Serviço de Aplicações Azure
Troubleshoot uma aplicação no Azure App Service
usando o Visual Studio
Descrição geral
Este tutorial mostra como usar as ferramentas do Estúdio Visual para ajudar a desinpurar uma aplicação no App
Service,executando remotamente o modo de depuração ou visualizando registos de aplicações e registos de
servidores web.
Irá aprender:
Quais as funções de gestão de aplicações disponíveis no Estúdio Visual.
Como utilizar a vista remota do Estúdio Visual para fazer mudanças rápidas numa aplicação remota.
Como executar o modo de depuração remotamente enquanto um projeto está em execução em Azure, tanto
para uma aplicação como para um WebJob.
Como criar registos de rastreio de aplicações e vê-los enquanto a aplicação os está a criar.
Como visualizar os registos do servidor web, incluindo mensagens de erro detalhadas e rastreio de pedidos
falhados.
Como enviar registos de diagnóstico para uma conta de Armazenamento Azure e vê-los lá.
Se tiver o Visual Studio Ultimate, também pode utilizar o IntelliTrace para depurar. O IntelliTrace não está coberto
neste tutorial.
Pré-requisitos
Este tutorial trabalha com o ambiente de desenvolvimento, o projeto web e a app App Service que criou na Create
uma aplicação ASP.NET no Azure App Service. Para as secções WebJobs, você precisará da aplicação que você cria
em Get Started com o Azure WebJobs SDK.
As amostras de código mostradas neste tutorial são para uma aplicação web C# MVC, mas os procedimentos de
resolução de problemas são os mesmos para aplicações De Base Visual e Formulários Web.
O tutorial assume que está a usar o Visual Studio 2019.
A função de registos de streaming funciona apenas para aplicações que visam o .NET Framework 4 ou posterior.
Configuração e gestão de aplicativos

O Visual Studio fornece acesso a um subconjunto das funções de gestão de aplicações e definições de
configuração disponíveis no portal Azure. Nesta secção, verá o que está disponível utilizando o Ser ver Explorer .
Para ver as mais recentes funcionalidades de integração do Azure, experimente também o Cloud Explorer. Pode
abrir ambas as janelas do menu 'Ver'.
1. Se ainda não tiver assinado no Azure no Estúdio Visual, clique no Azure e selecione Connect to Microsoft
Azure Subscription in Ser ver Explorer .
Uma alternativa é instalar um certificado de gestão que permita o acesso à sua conta. Se optar por instalar
um certificado, clique no nó Azure no Ser ver Explorer e, em seguida, selecione 'Gerir e Filtrar
Assinaturas' no menu de contexto. Na caixa de diálogo de assinaturas Manage Microsoft Azure,
clique no separador Cer tificados e, em seguida, clique em Impor tar . Siga as instruções para descarregar
e, em seguida, importe um ficheiro de subscrição (também chamado de ficheiro .publishsettings) para a
sua conta Azure.
NOTE
Se descarregar um ficheiro de subscrição, guarde-o para uma pasta fora dos diretórios do código fonte (por
exemplo, na pasta Downloads) e, em seguida, elimine-o assim que a importação estiver concluída. Um utilizador
malicioso que obtém acesso ao ficheiro de subscrição pode editar, criar e eliminar os seus serviços Azure.
Para obter mais informações sobre a ligação aos recursos do Azure a partir do Estúdio Visual, consulte
Gerir Contas, Subscrições e Funções Administrativas.
2. No Ser ver Explorer, expanda o Azure e expanda o Serviço de Aplicações.
3. Expanda o grupo de recursos que inclui a app que criou na Create a ASP.NET app no Azure App Service, e,
em seguida, clique no nó da aplicação e clique em Definições de Visualização .
O separador Azure Web App aparece e pode ver lá as tarefas de gestão e configuração de aplicações que
estão disponíveis no Estúdio Visual.
Neste tutorial, você usará a exploração madeireira e rastreio de quedas. Também utilizará depuração
remota, mas utilizará um método diferente para o ativar.
Para obter informações sobre as definições de aplicações e caixas de cordas de ligação nesta janela,
consulte o Serviço de Aplicações Azure: Como funcionam as cordas de aplicação e as cordasde ligação .
Se quiser realizar uma tarefa de gestão de aplicações que não possa ser feita nesta janela, clique em Open
in Management Por tal para abrir uma janela de navegador para o portal Azure.
Aceder a ficheiros de aplicativos no Server Explorer

Normalmente, você implementa customErrors um projeto web com a On bandeira RemoteOnly no ficheiro
Web.config definido para ou , o que significa que você não recebe uma mensagem de erro útil quando algo corre
mal. Para muitos erros, tudo o que obtém é uma página como uma das seguintes:
Erro do ser vidor na aplicação '/':
Ocorreu um erro:
O site não pode exibir a página

Frequentemente, a forma mais fácil de encontrar a causa do erro é ativar mensagens de erro detalhadas, o que a
primeira das imagens anteriores explica como fazer. Isto requer uma alteração no ficheiro Web.config implantado.
Pode editar o ficheiro Web.config no projeto e reimplantar o projeto, ou criar uma transformação web.config e
implementar uma construção de depuração, mas há uma maneira mais rápida: no Solution Explorer, pode
visualizar e editar ficheiros diretamente na aplicação remota utilizando a funcionalidade de visualização remota.
1. No Ser ver Explorer, expanda o Azure, expanda o App Ser vice, expanda o grupo de recursos em que a
sua aplicação está localizada e, em seguida, expanda o nó para a sua app.
Vê sosdes que lhe dão acesso aos ficheiros de conteúdo da aplicação e ficheiros de registo.
2. Expanda o nó dos Ficheiros e clique duas vezes no ficheiro Web.config.
O Visual Studio abre o ficheiro Web.config a partir da aplicação remota e mostra [Remote] ao lado do
nome do ficheiro na barra de título.
3. Adicione a seguinte system.web linha ao elemento:
<customErrors mode="Off"></customErrors>
4. Atualize o navegador que está a mostrar a mensagem de erro inútil, e agora recebe uma mensagem de
erro detalhada, como o seguinte exemplo:
(O erro mostrado foi criado adicionando a linha mostrada a vermelho a Views\Home\Index.cshtml.)

Editar o ficheiro Web.config é apenas um exemplo de cenários em que a capacidade de ler e editar ficheiros na
aplicação do Serviço de Aplicações facilita a resolução de problemas.
Aplicativos de depuração remoto

Se a mensagem de erro detalhada não fornecer informações suficientes e não conseguir recriar o erro
localmente, outra forma de resolver problemas é correr remotamente no modo de depuração. Pode definir
pontos de rutura, manipular a memória diretamente, passar pelo código e até alterar o código.
A depuração remota não funciona nas edições express do Visual Studio.
Esta secção mostra como depurar remotamente o projeto que cria na Create a ASP.NET app no Azure App Service.
1. Abra o projeto web que criou na Create a ASP.NET app no Azure App Service.
2. Controladores abertos\HomeController.cs.
3. Elimine About() o método e insira o seguinte código no seu lugar.
public ActionResult About()

{
string currentTime = DateTime.Now.ToLongTimeString();
ViewBag.Message = "The current time is " + currentTime;
return View();
}
4. Coloque um ponto ViewBag.Message de rutura na linha.

5. No Solution Explorer, clique no projeto e clique em Publicar .
6. Na lista de drop-down do Profile, selecione o mesmo perfil que utilizou na Create a ASP.NET app no Azure
App Service. Em seguida, clique em Definições.
7. No diálogo Publicar, clique no separador Definições e, em seguida, mude a Configuração para Debug ,
e, em seguida, clique em Guardar .
8. Clique em Publicar . Depois de terminar a implementação e o seu navegador abrir para o URL Azure da
sua aplicação, feche o navegador.
9. No Ser ver Explorer, clique na sua aplicação e clique em Attach Debugger .
O navegador abre automaticamente para a sua página inicial em funcionamento em Azure. Pode ter de
esperar 20 segundos enquanto o Azure configura o servidor para depuração. Este atraso só acontece na
primeira vez que corre em modo dedepura numa aplicação num período de 48 horas. Quando se volta a
depurar no mesmo período, não há atraso.
NOTE
Se tiver algum problema em iniciar o desordeiro, tente fazê-lo utilizando o Cloud Explorer em vez do Ser ver
Explorer .
10. Clique About no menu.

O Visual Studio para no ponto de rutura, e o código está a funcionar em Azure, não no computador local.
11. Pairar sobre currentTime a variável para ver o valor do tempo.
O tempo que vê é o tempo do servidor Azure, que pode estar num fuso horário diferente do seu
computador local.
12. Introduza um novo currentTime valor para a variável, como "Agora a correr em Azure".
13. Pressione F5 para continuar a correr.
A página Sobre em execução em Azure exibe o novo valor que introduziu na variável actualTime.
WebJobs de depuração remoto
Esta secção mostra como depurar remotamente o projeto e a aplicação que cria no Get Started com o Azure
WebJobs SDK.
As funcionalidades apresentadas nesta secção estão disponíveis apenas no Visual Studio 2013 com o Update 4 ou
mais tarde.
A depuração remota só funciona com WebJobs contínuos. WebJobs programado e a pedido não suporta mato.
1. Abra o projeto web que criou no Get Started com o Azure WebJobs SDK.
2. No projeto ContosoAdsWebJob, abra Functions.cs.
3. Detete um ponto de GnerateThumbnail rutura na primeira declaração do método.
4. No Solution Explorer, clique no projeto web (não no projeto WebJob) e clique em Publicar .
5. Na lista de drop-down do Profile, selecione o mesmo perfil que utilizou no Get Started com o Azure
WebJobs SDK.
6. Clique no separador Definições e mude de configuração para Debug, e depois clique em Publicar .
O Visual Studio implementa os projetos web e WebJob, e o seu navegador abre-se para o URL Azure da
sua aplicação.
7. No Ser ver Explorer, expanda o Azure > App Ser vice > o seu grupo de recursos > a sua
aplicação > WebJobs > Continuous , e, em seguida, clique no clique direito ContosoAdsWebJob .
8. Clique em prender debugger .
O navegador abre automaticamente para a sua página inicial em funcionamento em Azure. Pode ter de
esperar 20 segundos enquanto o Azure configura o servidor para depuração. Este atraso só acontece na
primeira vez que corre em modo dedepura numa aplicação num período de 48 horas. Quando se volta a
depurar no mesmo período, não há atraso.
9. No navegador web que é aberto à página inicial dos Anúncios Contoso, crie um novo anúncio.
A criação de um anúncio faz com que seja criada uma mensagem de fila, que é captada pelo WebJob e
processada. Quando o WebJobs SDK chama a função para processar a mensagem de fila, o código atinge o
seu ponto de rutura.
10. Quando o debugger quebra no seu ponto de rutura, você pode examinar e alterar valores variáveis
enquanto o programa está executando a nuvem. Na seguinte ilustração, o debugger mostra o conteúdo do
objeto GenerateThumbnail blobInfo que foi passado para o método.
11. Pressione F5 para continuar a correr.

O GenerateThumbnail método termina criando a miniatura.
12. No navegador, refresque a página Do Índice e veja a miniatura.
13. No Estúdio Visual, prima SHIFT+F5 para parar de depurar.
14. No Ser ver Explorer, clique à direita no nó ContosoAdsWebJob e clique em Ver Dashboard .
15. Inscreva-se com as suas credenciais Azure e, em seguida, clique no nome WebJob para ir à página para o
seu WebJob.
O Dashboard mostra GenerateThumbnail que a função foi executada recentemente.
(Da próxima vez que clicar no View Dashboard, não tem de iniciar sessão e o navegador vai diretamente
para a página do seu WebJob.)
16. Clique no nome da função para ver detalhes sobre a execução da função.
Se a sua função escreveu registos,pode clicar em ToggleOutput para os ver.

Notes about remote debugging (Notas sobre a depuração remota)
Não é aconselhável funcionar em modo de depuração em produção. Se a sua aplicação de produção não
for dimensionada para várias instâncias do servidor, a depuração impede que o servidor web responda a
outros pedidos. Se tiver várias instâncias de servidor web, quando se liga ao desbugger, obtém uma
instância aleatória, e não tem como garantir que os pedidos de navegador subsequentes vão para a
mesma instância. Além disso, normalmente não implementa uma construção de depuração para a
produção, e otimizações de compiladores para construções de lançamento podem tornar impossível
mostrar o que está a acontecer linha a linha no seu código fonte. Para problemas de resolução de
problemas de produção, o seu melhor recurso é o rastreio de aplicações e registos de servidores web.
Evite longas paragens nos pontos de rutura quando depurar remotamente. O Azure trata um processo que
é interrompido por mais de alguns minutos como um processo sem resposta, e desliga-o.
Enquanto está a depurar, o servidor está a enviar dados para o Visual Studio, o que pode afetar as cargas
de largura de banda. Para obter informações sobre as tarifas de largura de banda, consulte o Preço Do
Azure.
Certifique-se debug de que compilation o atributo do elemento no ficheiro Web.config está definido
como verdadeiro. É definido para verdade por padrão quando publica uma configuração de construção de
depuração.
<system.web>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" />
</system.web>
Se descobrires que o debugger não entra no código que queres depurar, talvez tenhas de mudar a
definição do Just My Code. Para mais informações, consulte Especifique se deve depurar apenaso código do
utilizador usando just o meu código em estúdio visual .
Um temporizador começa no servidor quando ativa a função de depuração remota e, após 48 horas, a
funcionalidade é desligada automaticamente. Este limite de 48 horas é feito por razões de segurança e
desempenho. Pode facilmente voltar a ligar a funcionalidade quantas vezes quiser. Recomendamos deixá-lo
desativado quando não estiver a depurar ativamente.
Pode ligar manualmente o debugger a qualquer processo, não apenas o processo da aplicação (w3wp.exe).
Para obter mais informações sobre como usar o modo dedepura no Estúdio Visual, consulte Debugging no
Visual Studio.
Visão geral dos registos de diagnóstico

Uma aplicação ASP.NET que funciona numa aplicação do App Service pode criar os seguintes tipos de registos:
Registos de rastreio de aplicação
A aplicação cria estes registos chamando métodos do Sistema.Diagnósticos.Trace class.
Registos de ser vidores web
O servidor web cria uma entrada de registo para cada pedido http para a aplicação.
Registos de mensagens de erro detalhados
O servidor web cria uma página HTML com algumas informações adicionais para pedidos DE HTTP falhados
(pedidos que resultam em código de estado 400 ou superior).
Registos de rastreio de pedidos falhados
O servidor web cria um ficheiro XML com informações detalhadas de rastreio para pedidos HTTP falhados. O
servidor web também fornece um ficheiro XSL para formatar o XML num browser.
O registo afeta o desempenho da aplicação, pelo que o Azure lhe dá a capacidade de ativar ou desativar cada tipo
de registo, conforme necessário. Para os registos de aplicação, pode especificar que apenas devem ser escritos
registos acima de um determinado nível de gravidade. Quando cria uma nova aplicação, por padrão, toda a
exploração madeireira está desativada.
Os registos são escritos para ficheiros numa pasta LogFiles no sistema de ficheiros da sua aplicação e são
acessíveis via FTP. Os registos e registos de aplicações do servidor web também podem ser escritos numa conta
de Armazenamento Azure. Pode reter um maior volume de registos numa conta de armazenamento do que é
possível no sistema de ficheiros. Está limitado a um máximo de 100 megabytes de registos quando utiliza o
sistema de ficheiros. (Os registos do sistema de ficheiros são apenas para retenção a curto prazo. O Azure elimina
ficheiros de registo antigos para dar espaço aos novos após o limite.)
Criar e ver registos de rastreios de aplicações

Nesta secção, você faz as seguintes tarefas:
Adicione declarações de rastreio ao projeto web que criou em Get started com Azure e ASP.NET.
Veja os registos quando executar o projeto localmente.
Veja os registos como são gerados pela aplicação em funcionamento em Azure.
Para obter informações sobre como criar registos de aplicações no WebJobs, consulte como trabalhar com o
armazenamento de fila Azure utilizando o WebJobs SDK - Como escrever registos. As seguintes instruções para
visualizar registos e controlar a forma como são armazenados em Azure aplicam-se também aos registos de
aplicações criados pela WebJobs.
Adicione declarações de rastreio à aplicação
1. Controladores abertos\HomeController.cs, Index About e Contact substitua os métodos e Trace
métodos using com System.Diagnostics o seguinte código, a fim de adicionar declarações e uma
declaração para:
public ActionResult Index()

{
Trace.WriteLine("Entering Index method");
ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";
Trace.TraceInformation("Displaying the Index page at " + DateTime.Now.ToLongTimeString());
Trace.WriteLine("Leaving Index method");
return View();
}
public ActionResult About()

{
Trace.WriteLine("Entering About method");
ViewBag.Message = "Your app description page.";
Trace.TraceWarning("Transient error on the About page at " + DateTime.Now.ToShortTimeString());
Trace.WriteLine("Leaving About method");
return View();
}
public ActionResult Contact()

{
Trace.WriteLine("Entering Contact method");
ViewBag.Message = "Your contact page.";
Trace.TraceError("Fatal error on the Contact page at " + DateTime.Now.ToLongTimeString());
Trace.WriteLine("Leaving Contact method");
return View();
}
2. Adicione using System.Diagnostics; uma declaração ao topo do ficheiro.

Veja a saída de rastreio localmente
1. Pressione F5 para executar a aplicação em modo dedepura.
O ouvinte de rastreio predefinido escreve todos os vestígios para a janela de saída, juntamente com outra
saída de Debug. A ilustração seguinte mostra a saída a Index partir das declarações de vestígios que
adicionou ao método.
Os seguintes passos mostram como visualizar a saída de vestígios numa página web, sem compilar em
modo dedepura.
2. Abra o ficheiro Web.config da aplicação (o que <system.diagnostics> está localizado na pasta do
</configuration> projeto) e adicione um elemento na extremidade do ficheiro pouco antes do elemento
de fecho:
<system.diagnostics>
<trace>
<listeners>
<add name="WebPageTraceListener"
type="System.Web.WebPageTraceListener,
System.Web,
Version=4.0.0.0,
Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
</listeners>
</trace>
</system.diagnostics>
O WebPageTraceListener permite-lhe visualizar a /trace.axd saída de vestígios navegando para .

1. Adicione um elemento <system.web> de traço no ficheiro Web.config, como o seguinte exemplo:
<trace enabled="true" writeToDiagnosticsTrace="true" mostRecent="true" pageOutput="false" />
2. Prima CTRL+F5 para executar a aplicação.

3. Na barra de endereços da janela do navegador, adicione trace.axd ao URL
http://localhost:53370/trace.axd e, em seguida, prima Enter (o URL é semelhante a ).
4. Na página 'Rastreio de Aplicação', clique em Ver Detalhes na primeira linha (não na linha BrowserLink).
A página Dedados de Pedido aparece e na secção Informação de Rastreio Index vê a saída a partir das
declarações de vestígios que adicionou ao método.
Por padrão, só está disponível localmente. Se quiser disponibilizá-lo a partir de

trace.axd
localOnly="false" uma trace aplicação remota, pode adicionar ao elemento no ficheiro Web.config,
como mostra o seguinte exemplo:
<trace enabled="true" writeToDiagnosticsTrace="true" localOnly="false" mostRecent="true"

pageOutput="false" />
No entanto, a habilitação trace.axd numa aplicação de produção não é recomendada por razões de
segurança. Nas seguintes secções, verá uma forma mais fácil de ler registos de rastreio numa aplicação do
App Service.
Veja a saída de rastreio em Azure
1. No Solution Explorer, clique no projeto web e clique em Publicar .
2. Na caixa de diálogo Publicar Web, clique em Publicar .
Depois de o Visual Studio publicar a sua atualização, abre uma janela de navegador para a sua página
inicial (assumindo que não limpou o URL de Destino no separador Ligação).
3. No Ser ver Explorer, clique na sua aplicação e selecione 'Ver Registos de Streaming'.
A janela Saída mostra que está ligado ao serviço de streaming de log e adiciona uma linha de notificação
a cada minuto que passa sem um registo para exibir.
4. Na janela do navegador que mostra a página inicial da sua aplicação, clique em Contato .
Dentro de alguns segundos, a saída do Contact traço de nível de erro que adicionou ao método aparece
na janela de saída.
O Visual Studio só está a mostrar vestígios de nível de erro porque é a definição padrão quando ativa o
serviço de monitorização de registos. Quando cria uma nova aplicação do App Service, todo o registo é
desativado por padrão, como viu quando abriu a página de definições mais cedo:
No entanto, quando selecionou registos de streaming de visualização, o Visual Studio alterou

automaticamente o registo de registos de aplicação (Sistema de Ficheiros) para Erro , o que significa
que os registos de nível de erro são reportados. Para ver todos os seus registos de rastreio, pode alterar
esta definição para Verbose . Quando se leciona um nível de gravidade inferior ao erro, todos os registos
para níveis de gravidade mais elevados também são relatados. Assim, quando seleciona verboso, também
vê registos de informação, aviso e erro.
5. No Ser ver Explorer, clique na aplicação e clique em 'Ver Definições', como fez anteriormente.
6. Alterar a registo de aplicações (Sistema de Ficheiros) para Verbose, e depois clicar em Guardar .
7. Na janela do navegador que agora mostra a sua página de Contacto, clique em Casa, clique em About , e,
em seguida, clique em Contato .
Dentro de alguns segundos, a janela de saída mostra toda a sua saída de rastreio.
Nesta secção, ativou e desativou o registo através das definições da aplicação. Também pode ativar e
desativar os ouvintes modificando o ficheiro Web.config. No entanto, modificar o ficheiro Web.config faz
com que o domínio da aplicação recicle, ao mesmo tempo que permitir o registo através da configuração
da aplicação não o faz. Se o problema demorar muito tempo a reproduzir-se, ou for intermitente, reciclar o
domínio da aplicação pode "consertá-lo" e forçá-lo a esperar até que volte a acontecer. Ativar diagnósticos
em Azure permite-lhe começar a capturar informações de erro imediatamente sem reciclar o domínio da
aplicação.
Características da janela de saída
O separador de registos Microsoft Azure da Janela de Saída tem vários botões e uma caixa de texto:
Estes desempenham as seguintes funções:

Limpe a janela de saída.
Ativar ou desativar o embrulho de palavras.
Inicie ou pare de monitorizar os registos.
Especifique quais os registos a monitorizar.
Descarregue os registos.
Filtrar os registos com base numa cadeia de pesquisa ou numa expressão regular.
Feche a janela de saída.
Se introduzir uma cadeia de pesquisa ou expressão regular, o Visual Studio filtra o registo de informações no
cliente. Isto significa que pode introduzir os critérios após a visualização dos registos na janela Saída e pode
alterar os critérios de filtragem sem ter de regenerar os registos.
Ver registos de servidores web

Os registos do servidor web registam todas as atividades do HTTP para a aplicação. Para vê-los na janela Output,
deve ative-os para a aplicação e diga ao Visual Studio que pretende monitorizá-los.
1. No separador de configuração da aplicação Web Azure que abriu do Ser ver Explorer, altere o Registo
do Servidor Web para On e, em seguida, clique em Guardar .
2. Na janela de saída, clique no especte do microsoft Azure para monitorizar o botão.
3. Na caixa de diálogo Microsoft Azure Logging Options, selecione registos do servidor Web e, em
seguida, clique em OK .
4. Na janela do navegador que mostra a aplicação, clique em Casa, depois clique em About , e depois clique
em Contato .
Os registos de aplicação geralmente aparecem primeiro, seguidos dos registos do servidor web. Talvez
tenha que esperar um pouco para que os troncos apareçam.
Por predefinição, quando ativa os registos do servidor web utilizando o Visual Studio, o Azure escreve os registos
para o sistema de ficheiros. Como alternativa, pode utilizar o portal Azure para especificar que os registos do
servidor web devem ser escritos a um recipiente de blob numa conta de armazenamento.
Se utilizar o portal para permitir o registo do servidor web numa conta de armazenamento Azure e, em seguida,
desativar o registo no Estúdio Visual, quando reativa o registo no Estúdio Visual, as definições da sua conta de
armazenamento são restauradas.
Ver registos de mensagens de erro detalhados

Os registos de erros detalhados fornecem algumas informações adicionais sobre pedidos http que resultam em
códigos de resposta a erros (400 ou mais). Para vê-los na janela Output, tem de os ativar para a aplicação e dizer
ao Visual Studio que pretende monitorizá-los.
1. No separador de configuração da aplicação Web Azure que abriu do Ser ver Explorer, altere as
mensagens de erro detalhadas para on e, em seguida, clique em Guardar .
2. Na janela de saída, clique no especte do microsoft Azure para monitorizar o botão.
3. Na caixa de diálogo Microsoft Azure Logging Options, clique em todos os registos, e clique em OK .
4. Na barra de endereços da janela do navegador, adicione um carácter extra ao

http://localhost:53370/Home/Contactx URL para causar um erro 404 (por exemplo, e prima Enter.
Após vários segundos, o registo de erros detalhado aparece na janela de saída do Estúdio Visual.
Controle+clique no link para ver a saída de log formatada num browser:

Descarregue registos do sistema de ficheiros
Quaisquer registos que possa monitorizar na janela Saída também podem ser descarregados como um ficheiro
.zip.
1. Na janela Saída, clique em Download Streaming Logs .
O File Explorer abre-se para a pasta Downloads com o ficheiro descarregado selecionado.
2. Extraio o ficheiro .zip e vê a seguinte estrutura de pasta:
Os registos de rastreio de aplicações estão em ficheiros .txt na pasta LogFiles\Application.

Os registos do servidor web estão em ficheiros .log na pasta LogFiles\http\RawLogs. Pode utilizar
uma ferramenta como log Parser para visualizar e manipular estes ficheiros.
Os registos de mensagens de erro detalhados estão em ficheiros .html na pasta
LogFiles\DetailedErrors.
(A pasta de implementações destina-se a ficheiros criados pela publicação de controlo de fontes;
não tem nada relacionado com a publicação do Visual Studio. A pasta Git destina-se a vestígios
relacionados com a publicação do controlo de fonte e o serviço de streaming de ficheiros de
registo.)
Ver registos de rastreio de pedidos falhados

Os registos de rastreio de pedidos falhados são úteis quando precisa de compreender os detalhes de como o IIS
está a lidar com um pedido http, em cenários como reescrita de URL ou problemas de autenticação.
As aplicações do Serviço de Aplicações utilizam a mesma funcionalidade de rastreio de rastreio de pedidos
falhado que foi disponibilizada com o IIS 7.0 e posteriormente. No entanto, não tem acesso às definições do IIS
que configuram quais os erros que são registados. Quando ativa o rastreio de pedidos falhado, todos os erros são
capturados.
Pode ativar o rastreio de pedidos falhadoutilizando o Visual Studio, mas não pode vê-los no Visual Studio. Estes
registos são ficheiros XML. O serviço de registo de streaming apenas monitoriza ficheiros que são considerados
legíveis no modo de texto simples: .txt, .html, e .log ficheiros.
Pode visualizar registos de rastreio de pedidos falhados num navegador diretamente via FTP ou localmente
depois de usar uma ferramenta FTP para descarregá-los para o seu computador local. Nesta secção, irá vê-los
diretamente num navegador.
1. No separador de configuração da janela Web App Azure que abriu do Ser ver Explorer, altere o
Rastreio de Pedido Falhado para On e, em seguida, clique em Guardar .
2. Na barra de endereços da janela do navegador que mostra a aplicação, adicione um personagem extra ao
URL e clique em Enter para causar um erro de 404.
Isto faz com que seja criado um registo de rastreio de rastreio de pedidos falhado, e os seguintes passos
mostram como visualizar ou descarregar o registo.
3. No Estúdio Visual, no separador de configuração da janela Da Web App Azure, clique em Open in
Management Por tal .
4. Na página definições do portal Azure para a sua aplicação, clique em credenciais de implementação e,
em seguida, introduza um novo nome de utilizador e palavra-passe.
NOTE
Quando iniciar sessão, tem de utilizar o nome completo do utilizador com o nome da aplicação prefixado. Por
exemplo, se introduzir "myid" como nome de utilizador e o site for "o meu exemplo", você entra como
"myexample\myid".
5. Numa nova janela de navegador, vá ao URL que é mostrado sob o nome de anfitrião FTP ou ftps na
página 'Over view' para a sua aplicação.
6. Inscreva-se utilizando as credenciais FTP que criou anteriormente (incluindo o prefixo de nome da
aplicação para o nome do utilizador).
O navegador mostra a pasta raiz da aplicação.
7. Abra a pasta LogFiles.
8. Abra a pasta que se chama W3SVC mais um valor numérico.
A pasta contém ficheiros XML para quaisquer erros que tenham sido registados após o rastreio de pedido
falhado ativado, e um ficheiro XSL que um navegador pode usar para formatar o XML.
9. Clique no ficheiro XML para obter o pedido falhado para o qual pretende ver informações de rastreio.
A ilustração que se segue mostra parte da informação de rastreio para um erro de amostra.
Próximos Passos
Já viu como o Visual Studio facilita a visualização de registos criados por uma aplicação de Serviço de Aplicações.
As seguintes secções fornecem ligações a mais recursos sobre temas relacionados:
Resolução de problemas do Serviço de Aplicações
Depuração em Estúdio Visual
Depuração remota em Azure
Rastreio em aplicações ASP.NET
Analisar registos de servidores web
Analisar registos de rastreio de pedidos falhados
Depuração de serviços de nuvem
Resolução de problemas do Serviço de Aplicações
Para obter mais informações sobre aplicações de resolução de problemas no Azure App Service, consulte os
seguintes recursos:
Como monitorizar aplicações
Investigar fugas de memória no Serviço de Aplicações Azure com o Estúdio Visual 2013. Post de blog da
Microsoft ALM sobre funcionalidades do Estúdio Visual para analisar problemas de memória geridos.
Ferramentas online do Azure App Service que deve conhecer. Post de blog de Amit Apple.
Para ajudar com uma questão específica de resolução de problemas, inicie um fio num dos seguintes fóruns:
O fórum Azure no local ASP.NET.
O fórum Azure no Microsoft Q&A.
StackOverflow.com.
Depuração em Estúdio Visual
Para obter mais informações sobre como usar o modo dedepura no Visual Studio, consulte Debugging no Visual
Studio e Debugging Tips com Visual Studio 2010.
Depuração remota em Azure
Para obter mais informações sobre depuração remota para aplicações de Serviço saem e WebJobs, consulte os
seguintes recursos:
Introdução ao Serviço de Aplicações Azure Debugging Remoto.
Introdução ao Serviço de Aplicações Azure Debugging Remoto parte 2 - Depuração remota
Introdução à Depuração Remota no Serviço de Aplicações Azure parte 3 - Ambiente multi-instância e GIT
Depuração webJobs (vídeo)
Se a sua aplicação utilizar um Back-end Azur API ou Mobile Services e tiver de o desmarcar, consulte Debugging
.NET Backend em Visual Studio.
Rastreio em aplicações ASP.NET
Não existem introduções completas e atualizadas para ASP.NET rastreio disponível na Internet. O melhor que
pode fazer é começar com materiais introdutórios antigos escritos para Formulários Web porque o MVC ainda
não existia, e complementá-lo com publicações de blogmais recentes que se focam em questões específicas.
Alguns bons lugares para começar são os seguintes recursos:
Monitorização e Telemetria (Building Real-World Cloud Apps with Azure).
Capítulo do e-book com recomendações para rastreio em aplicações em nuvem Azure.
ASP.NET Rastreio
Antigo, mas ainda um bom recurso para uma introdução básica ao assunto.
Rastrear ouvintes
Informações sobre os ouvintes de rastreio, mas não menciona o WebPageTraceListener.
Walkthrough: Integração ASP.NET Rastreio com Sistema.Rastreio de Diagnósticos
Este artigo também é antigo, mas inclui algumas informações adicionais que o artigo introdutório não
cobre.
Rastreio em ASP.NET Vistas da Navalha MVC
Além de rastrear nas vistas da Razor, o post também explica como criar um filtro de erro para registar
todas as exceções não tratadas numa aplicação MVC. Para obter informações sobre como registar todas as
exceções não tratadas numa aplicação de Formulários Web, consulte o exemplo Global.asax em Completo
Exemplo para Manipuladores de Erros na MSDN. Em MVC ou Formulários Web, se pretender registar
certas exceções, mas deixar que o manuseamento de quadros predefinidos faça efeito para eles, pode
capturar e relançar como no seguinte exemplo:
try
{
// Your code that might cause an exception to be thrown.
}
catch (Exception ex)
{
Trace.TraceError("Exception: " + ex.ToString());
throw;
}
Diagnósticos de streaming Trace Logging from the Azure Command Line (plus Glimpse!)
Como usar a linha de comando para fazer o que este tutorial mostra como fazer no Estúdio Visual. O
vislumbre é uma ferramenta para depurar aplicações ASP.NET.
Usando web apps Logging and Diagnostics - com David Ebbo e Streaming Logs de Web Apps - com David
Ebbo
Vídeos de Scott Hanselman e David Ebbo.
Para a exploração por erros, uma alternativa à escrita do seu próprio código de rastreio é utilizar uma estrutura de
registo de código aberto, como elmah. Para mais informações, consulte as publicações de Scott Hanselman sobre
a ELMAH.
Além disso, não precisa de System.Diagnostics usar ASP.NET ou rastrear para obter registos de streaming do
Azure. O serviço de streaming de ficheiros de streaming da aplicação App Service transmite qualquer .txt, .html,
ou .log file que encontre na pasta LogFiles. Por isso, poderá criar o seu próprio sistema de registo que escreve
para o sistema de ficheiros da aplicação, e o seu ficheiro é automaticamente transmitido e descarregado. Tudo o
que tem de fazer é escrever código de aplicação que cria ficheiros na pasta d:\home\logfiles.
Analisar registos de servidores web
Para obter mais informações sobre a análise de registos de servidores web, consulte os seguintes recursos:
LogParser
Uma ferramenta para visualizar dados em registos de servidores web (ficheiros .log).
Resolução de problemas Problemas de Problemas problemas de desempenho ou erros de aplicação usando
LogParser
Uma introdução à ferramenta Log Parser que pode utilizar para analisar registos de servidores web.
Posts de blog de Robert McMurray sobre a utilização de LogParser
O código de estado HTTP no IIS 7.0, IIS 7.5 e IIS 8.0
Analisar registos de rastreio de pedidos falhados
O website da Microsoft TechNet inclui uma secção de Rastreio de Pedidos Falhados, que pode ser útil para
entender como usar estes registos. No entanto, esta documentação centra-se principalmente na configuração do
rastreio de pedidos falhados no IIS, o que não pode fazer no Azure App Service.
Boas práticas e guia de resolução de problemas para
aplicações de nó no Azure App Service Windows
Neste artigo, aprende as melhores práticas e passos de resolução de problemas para aplicações de nó em
execução no Azure App Service (com iisnode).
WARNING
Tenha cuidado ao utilizar passos de resolução de problemas no seu local de produção. A recomendação é resolver problemas
na sua aplicação numa configuração de não produção, por exemplo, a sua ranhura de preparação e quando o problema for
corrigido, troque a sua ranhura de preparação com a sua ranhura de produção.
Configuração IISNODE
Este ficheiro de esquema sintetiza todas as definições que pode configurar para iisnode. Algumas das definições
que são úteis para a sua aplicação:
nodeProcessCountPerApplication
Esta definição controla o número de processos de nó que são lançados por aplicação IIS. O valor predefinido é 1.
Pode lançar tantos nó.ex como a contagem vCPU VM, alterando o valor para 0. O valor recomendado é 0 para a
maioria das aplicações para que possa utilizar todos os vCPUs na sua máquina. O nó.exe é de roscar-se para que
um nó.exe consuma um máximo de 1 vCPU. Para obter o máximo desempenho da sua aplicação de nó, você deseja
usar todos os vCPUs.
nodeProcessCommandLine
Esta definição controla o caminho para o nó.exe. Pode definir este valor para apontar para a sua versão nó.exe.
maxConcurrentRequestsPerProcess
Esta definição controla o número máximo de pedidos simultâneos enviados por ísóno a cada nó.exe. No Serviço de
Aplicações Azure, o valor padrão é Infinito. Pode configurar o valor dependendo do número de pedidos que a sua
aplicação recebe e da rapidez com que a sua aplicação processa cada pedido.
maxNamePipeConnectionRetry
Esta definição controla o número máximo de vezes que o iisnode se retenta fazendo a ligação no tubo nomeado
para enviar os pedidos para o nó.exe. Esta definição em combinação com o denominadoPipeConnectionRetryDelay
determina o tempo total de cada pedido dentro do iisnode. O valor padrão é de 200 no Serviço de Aplicações
Azure. Tempo total em segundos = (maxNamedPipeConnectionRetry * chamadoPipeConnectionRetryDelay) /
1000
nomeadoPipeConnectionRetryDelay
Esta definição controla a quantidade de tempo (em ms) que o iisnode aguarda entre cada nova tentativa para
enviar o pedido para nó.exe sobre o tubo nomeado. O valor padrão é de 250 ms. Tempo total em segundos =
(maxNamedPipeConnectionRetry * chamadoPipeConnectionRetryDelay) / 1000
Por padrão, o tempo total de iisnode no Serviço * de Aplicações Azure é de 200 250 ms = 50 segundos.
logDirectory
Esta definição controla o diretório onde os logs de iisnode stdout/stderr. O valor padrão é o iisnode, que é relativo
ao diretório principal do script (diretório onde o servidor principal.js está presente)
debuggerExtensionDll
Esta definição controla a versão do iisnódodo do inspetor de nós que utiliza ao depurar a aplicação do nó.
Atualmente, o iisnode-inspector-0.7.3.dll e o iisnode-inspector.dll são os dois únicos valores válidos para esta
definição. O valor por defeito é iisnode-inspector-0.7.3.dll. A versão iisnode-inspector-0.7.3.dll utiliza o nó-
inspector-0.7.3 e utiliza tomadas web. Ative as tomadas web no seu webapp Azure para utilizar esta versão.
Consulte https://ranjithblogs.azurewebsites.net/?p=98 mais detalhes sobre como configurar o iisnode para utilizar
o novo inspetor de nó.
flushResponse
O comportamento padrão do IIS é que tampona dados de resposta até 4 MB antes de flushing, ou até o final da
resposta, o que vier primeiro. O iisnode oferece uma configuração de configuração para sobrepor este
comportamento: para descarregar um fragmento do corpo da entidade iisnode/@flushResponse de resposta
assim que o iisnode o receber do nó.exe, é necessário definir o atributo em web.config para 'verdadeiro':
<configuration>
<system.webServer>

<iisnode flushResponse="true" />
</system.webServer>
</configuration>
Ativar a descarga de cada fragmento do corpo da entidade de resposta adiciona a sobrecarga de desempenho que
reduz a entrada do sistema em ~5% (a partir de v0.1.13). O melhor para analisar esta definição apenas para
pontos <location> finais que requerem streaming de resposta (por exemplo, utilizando o elemento na web.config)
Além disso, para aplicações de streaming, também deve definir a respostaBufferLimit do seu manipulador de
iisnode para 0.
<handlers>
<add name="iisnode" path="app.js" verb="\*" modules="iisnode" responseBufferLimit="0"/>
</handlers>
watchfiles
Uma lista separada do ponto-semi-cólon de ficheiros que são vigiadas para alterações. Qualquer alteração a um
ficheiro faz com que a aplicação recicle. Cada entrada consiste num nome de diretório opcional, bem como num
nome de ficheiro exigido, relativo ao diretório onde se encontra o principal ponto de entrada da aplicação. Cartões
selvagens são permitidos apenas na porção de nome de ficheiro. O valor predefinido é *.js;iisnode.yml
reciclarSignalEnabled
O valor predefinido é false. Se ativado, a aplicação do nó pode ligar-se_a_um tubo denominado (variável ambiental
IISNODE CONTROL PIPE) e enviar uma mensagem de "reciclagem". Isto faz com que o W3WP recicle
graciosamente.
idlePageOutTimePeriod
O valor predefinido é 0, o que significa que esta funcionalidade está desativada. Quando definido para um valor
superior a 0, o iisnode irá páginar todos os seus processos infantis em milissegundos. Consulte a documentação
para entender o que significa a página. Esta definição é útil para aplicações que consomem uma elevada
quantidade de memória e querem pager a memória para o disco ocasionalmente para libertar ram.
WARNING
Tenha cuidado ao ativar as seguintes definições de configuração nas aplicações de produção. A recomendação é não permitir
que se instem aplicações de produção ao vivo.
debugHeaderEnabled
O valor predefinido é false. Se for definido como verdadeiro, o iisnode adiciona um cabeçalho iisnode-debug de
resposta HTTP a cada resposta HTTP que envia o valor do iisnode-debug cabeçalho é um URL. Peças individuais de
informação de diagnóstico podem ser obtidas olhando para o fragmento de URL, no entanto, uma visualização
está disponível abrindo o URL num navegador.
exploração madeireiraHabilitada
Esta definição controla o registo de stdout e stderr por ísóno. Iisnode captura stdout/stderr dos processos de nó
que lança e escreve para o diretório especificado na definição 'logDirectory'. Uma vez ativada, a sua aplicação
escreve registos para o sistema de ficheiros e, dependendo da quantidade de registo feito pela aplicação, pode
haver implicações de desempenho.
devErrorsEnabled
O valor predefinido é false. Quando definido como verdadeiro, o iisnode apresenta o código de estado HTTP e o
código de erro Win32 no seu navegador. O código win32 é útil para depurar certos tipos de problemas.
depuraçãoEnabled (não permitir no local de produção ao vivo )
Esta definição controla a função de depuração. Iisnode está integrado com o inspetor do nó. Ao ativar esta
definição, permite a depuração da aplicação do nó. Ao permitir esta definição, o iisnode cria ficheiros de inspetor
de nós no diretório 'debuggerVirtualDir' no primeiro pedido de depuração para a sua aplicação de nó. Você pode
carregar o inspetor de nó, enviando um pedido para http://yoursite/server.js/debug . Pode controlar o segmento
DEURL de depuração com a definição 'debuggerPathSegment'. Por predefinição, debuggerPathSegment='debug'.
Pode definir debuggerPathSegment um GUID, por exemplo, para que seja mais difícil ser descoberto por outros.
Leia as aplicações Debug node.js no Windows para obter mais detalhes sobre a depuração.
Cenários e recomendações/resolução de problemas

O meu pedido de nó está a fazer chamadas excessivas de saída.
Muitas aplicações gostariam de fazer ligações de saída como parte do seu funcionamento regular. Por exemplo,
quando um pedido chega, a sua app de nó quereria contactar uma API REST em outro lugar e obter algumas
informações para processar o pedido. Você gostaria de usar um agente para manter vivo ao fazer chamadas http
ou https. Podes usar o módulo de agentekeepalive como agente para manter vivo ao fazer estas chamadas de
saída.
O módulo agentkeepalive garante que as tomadas são reutilizadas no seu VM webapp Azure. A criação de uma
nova tomada em cada pedido de saída adiciona sobrecarga à sua aplicação. Ter as tomadas de reutilização da sua
aplicação para pedidos de saída garante que a sua aplicação não excede as maxSockets que são atribuídas por VM.
A recomendação sobre o Serviço de Aplicações Azure é definir o valor maxSockets do * agenteKeepAlive para um
total de (4 instâncias de nó.exe 40 maxSockets/instância) 160 tomadas por VM.
Configuração do agente de exemploKeepALive:
let keepaliveAgent = new Agent({
maxSockets: 40,
maxFreeSockets: 10,
timeout: 60000,
keepAliveTimeout: 300000
});
IMPORTANT
Este exemplo pressupõe que tem 4 nós.exe em execução no seu VM. Se tiver um número diferente de nó.exe em execução
no VM, deve modificar a definição maxSockets em conformidade.
A minha aplicação de nó está a consumir demasiado CPU

Poderá receber uma recomendação do Azure App Service no seu portal sobre o elevado consumo de CPU.
Também pode configurar monitores para vigiar certas métricas. Ao verificar a utilização do CPU no Painel do Portal
Azure,verifique os valores MAX para CPU para que não perca os valores máximos. Se acredita que a sua aplicação
está a consumir demasiado CPU e não consegue explicar porquê, pode perfilar a sua aplicação de nó para
descobrir.
Perfilde a sua aplicação de nó no Serviço de Aplicações Azure com Perfil V8
Por exemplo, digamos que tem uma aplicação hello world que quer perfilar da seguinte forma:
const http = require('http');

function WriteConsoleLog() {
for(let i=0;i<99999;++i) {
console.log('hello world');
}
}
function HandleRequest() {
WriteConsoleLog();
}
http.createServer(function (req, res) {

res.writeHead(200, {'Content-Type': 'text/html'});
HandleRequest();
res.end('Hello world!');
}).listen(process.env.PORT);
Ir ao site da Consola Debug https://yoursite.scm.azurewebsites.net/DebugConsole

Entre no seu diretório site/wwwroot. Vê um pedido de comando como mostrado no seguinte exemplo:
Execute o comando npm install v8-profiler .
Este comando instala o perfil v8_sob o diretório de módulos de nó e todas as suas dependências. Agora, edite o
seu servidor.js para perfilar a sua aplicação.
const http = require('http');

const profiler = require('v8-profiler');
const fs = require('fs');
function WriteConsoleLog() {
for(let i=0;i<99999;++i) {
console.log('hello world');
}
}
function HandleRequest() {
profiler.startProfiling('HandleRequest');
WriteConsoleLog();
fs.writeFileSync('profile.cpuprofile', JSON.stringify(profiler.stopProfiling('HandleRequest')));
}
http.createServer(function (req, res) {

res.writeHead(200, {'Content-Type': 'text/html'});
HandleRequest();
res.end('Hello world!');
}).listen(process.env.PORT);
Os perfis de código anteriores da função WriteConsoleLog e, em seguida, escreve a saída de perfil para o ficheiro
'profile.cpuprofile' no seu site wwwroot. Envie um pedido para o seu pedido. Você vê um ficheiro
'profile.cpuprofile' criado sob o seu site wwwroot.
Descarregue este ficheiro e abra-o com as Ferramentas Chrome F12. Prima F12 no Chrome e, em seguida, escolha
o separador Perfis. Escolha o botão carregar. Selecione o ficheiro profile.cpuprofile do seu perfil que
descarregou. Clique no perfil que acabou de carregar.
Pode ver que 95% do tempo foi consumido pela função WriteConsoleLog. A saída também mostra os números de
linha exatos e os ficheiros de origem que causaram o problema.
A minha aplicação de nó está a consumir demasiada memória.
Se a sua aplicação estiver a consumir demasiada memória, vê um aviso do Serviço de Aplicações Azure no seu
portal sobre o elevado consumo de memória. Pode configurar monitores para vigiar certas métricas. Ao verificar o
uso da memória no Painel do Portal Azure,certifique-se de verificar se há memória dos valores MAX para que não
perca os valores de pico.
Deteção de fugas e Heap Diff para nó.js
Pode usar o memwatch do nó para ajudá-lo a identificar fugas de memória. Pode instalar-se memwatch tal como o
perfil v8 e editar o seu código para capturar e difundir pilhas para identificar as fugas de memória na sua
aplicação.
O meu nó.exe's está a ser morto aleatoriamente.
Há algumas razões pelas quais o nó.exe é desligado aleatoriamente:
1. A sua aplicação está a lançar\\exceções\\não apanhadas – Verifique d: registo de registos em casa Ficheiro de
registo de erros.txt para obter os detalhes sobre a exceção lançada. Este ficheiro tem o traço da pilha para
ajudar a depurar e corrigir a sua aplicação.
2. A sua aplicação está a consumir demasiada memória, o que está a afetar outros processos desde o início. Se a
memória VM total estiver perto de 100%, o seu nó.exe pode ser morto pelo gestor do processo. O gestor de
processos mata alguns processos para permitir que outros processos possam fazer algum trabalho. Para
corrigir este problema, desmepresente o seu pedido de fugas de memória. Se a sua aplicação necessitar de
grandes quantidades de memória, aumente até um VM maior (o que aumenta a RAM disponível para o VM).
A minha aplicação de nó não começa.
Se a sua aplicação estiver a devolver 500 Erros quando começar, pode haver algumas razões:
1. O nó.exe não está presente no local certo. Verifique a definição de nodeProcessCommandLine.
2. O ficheiro principal do script não está presente no local correto. Verifique web.config e certifique-se de que o
nome do ficheiro principal do script na secção de manipuladores corresponde ao ficheiro principal do script.
3. A configuração Web.config não está correta – verifique os nomes/valores das definições.
4. Arranque a frio – A sua aplicação está a demorar muito tempo a ser iniciada. Se a sua aplicação demorar mais *
do que (maxNamedPipeConnectionRetrynome chamadoPipeConnectionRetryDelay) / 1000 segundos, o
iisnode devolve um erro de 500. Aumente os valores destas definições para corresponder à hora de início da
sua aplicação para evitar que o iisnode saia e desatifique o erro de 500.
A minha aplicação de nó despenhou-se.
A sua aplicação está a d:\\home\\LogFiles\\Application\\logging-errors.txt lançar exceções não apanhadas –
Verifique o ficheiro para obter os detalhes da exceção lançada. Este ficheiro tem o traço da pilha para ajudar a
diagnosticar e corrigir a sua aplicação.
A minha aplicação de nó leva muito tempo para começar (Início frio )
A causa comum para longos tempos de início_de aplicação é um elevado número de ficheiros nos módulos do nó.
A aplicação tenta carregar a maioria destes ficheiros quando começa. Por predefinição, uma vez que os seus
ficheiros estão armazenados na partilha da rede no Serviço de Aplicações Azure, carregar muitos ficheiros pode
demorar algum tempo. Algumas soluções para tornar este processo mais rápido são:
1. Certifique-se de que tem uma estrutura de dependência plana e nenhuma dependência duplicada utilizando o
npm3 para instalar os seus módulos.
2. Tente carregar os_módulos de nó preguiçosos e não carregue todos os módulos no início da aplicação. Para os
módulos de carga preguiçosos, a chamada a exigir ('módulo') deve ser feita quando realmente precisa do
módulo dentro da função antes da primeira execução do código do módulo.
3. O Azure App Service oferece uma funcionalidade chamada cache local. Esta funcionalidade copia o seu
conteúdo desde a partilha de rede até ao disco local no VM. Como os ficheiros são locais,_o tempo de carga dos
módulos de nó é muito mais rápido.
Estatuto e subestatuto do IISNODE

O cnodeconstants ficheiro fonte lista todas as possíveis combinações de estado/subestatuto que o iisnode pode
devolver devido a um erro.
Ative o FREB para a sua aplicação ver o código de erro win32 (certifique-se de que ativa a FREB apenas em sites
não produtivos por razões de desempenho).
ESTA DO H T T P SUB ESTAT UTO H T T P P O SSÍVEL RA Z Ã O ?
500 1000 Houve algum problema a enviar o

pedido para o IISNODE – Verificar se o
nó.exe foi iniciado. O nó.exe pode ter
caído quando começou. Verifique se a
configuração web.config está a verificar
se há erros.
500 1001 - Win32Error 0x2 - A app não responde

ao URL. Verifique as regras de reescrita
do URL ou verifique se a sua aplicação
expressa tem as rotas corretas
definidas. - Win32Error 0x6d – o tubo
nomeado está ocupado – O Node.exe
não aceita pedidos porque o tubo está
ocupado. Verifique o alto uso do CPU. -
Outros erros - verifique se o nó.exe se
despenhou.
500 1002 Node.exe crashed –\check\d: home

LogFiles\logging-errors.txt for stack
trace.
500 1003 Problema de configuração do tubo – A

configuração do tubo nomeado está
incorreta.
500 1004-1018 Houve algum erro ao enviar o pedido

ou processar a resposta para/a partir
do nó.exe. Verifique se o nó.exe se
despenhou. verificar\d:\home\LogFiles
log-errors.txt para rastrear o rastreio da
pilha.
503 1000 Não há memória suficiente para alocar

ligações de tubos mais nomeadas.
Verifique por que a sua aplicação está a
consumir tanta memória. Verifique o
valor de definição
maxConcurrentRequestSPerProcess. Se
não é infinito e tem muitos pedidos,
aumente este valor para evitar este
erro.
503 1001 O pedido não pôde ser enviado para

nó.exe porque o pedido é reciclagem.
Depois de o pedido ter sido reciclado,
os pedidos devem ser servidos
normalmente.
503 1002 Verifique o código de erro win32 por

razão real – O pedido não pôde ser
enviado para um nó.exe.
ESTA DO H T T P SUB ESTAT UTO H T T P P O SSÍVEL RA Z Ã O ?
503 1003 O tubo nomeado é muito ocupado –

Verifique se o nó.exe está a consumir
CPU excessivo
Node.exe tem uma NODE_PENDING_PIPE_INSTANCES definição chamada . No Serviço de Aplicações Azure, este valor
está definido para 5000. O que significa que o nó.exe pode aceitar 5000 pedidos de cada vez no cano nomeado.
Este valor deve ser bom o suficiente para a maioria das aplicações de nó que estão em execução no Serviço de
Aplicações Azure. Você não deve ver 503.1003 no Azure App Service devido ao alto valor para o
NODE_PENDING_PIPE_INSTANCES
Mais recursos
Siga estes links para saber mais sobre aplicações no nó.js no Serviço de Aplicações Azure.
Introdução às aplicações Web Node.js no Serviço de Aplicações do Azure
Como depurar uma aplicação Web Node.js no App Service do Azure
Utilizar Módulos do Node.js com aplicações do Azure
Web Apps do App Service do Azure: Node.js
Centro de Programadores do Node.js
Explorar a Consola de Depuração do Kudu Super Secreta
Resolução de problemas ERROS HTTP de "502 bad
gateway" e "serviço 503 indisponível" no Azure App
Service
"502 bad gateway" e "503 service inavailable" são erros comuns na sua aplicação hospedada no Azure App Service.
Este artigo ajuda-o a resolver estes erros.
Se precisar de mais ajuda em qualquer ponto deste artigo, pode contactar os especialistas da Azure nos fóruns
msdn azure e nos fóruns Stack Overflow. Em alternativa, também pode apresentar um incidente de suporte Azure.
Vá ao site de suporte do Azure e clique em Obter Supor te.
Sintoma
Quando navega na aplicação, devolve um erro HTTP "502 Bad Gateway" ou um erro HTTP "Serviço Indisponível"
HTTP.
Causa
Este problema é muitas vezes causado por problemas de nível de aplicação, tais como:
pedidos que demoram muito tempo
aplicação usando alta memória/CPU
aplicação crashing devido a uma exceção.
Medidas de resolução de problemas para resolver erros de "502 bad

gateway" e "503 serviços indisponíveis"
A resolução de problemas pode ser dividida em três tarefas distintas, por ordem sequencial:
1. Observar e monitorizar o comportamento da aplicação
2. Recolher dados
3. Atenuar a questão
O Serviço de Aplicações oferece-lhe várias opções em cada passo.
Saúde do Serviço de Rastreio
O Microsoft Azure divulga cada vez que há uma interrupção de serviço ou degradação de desempenho. Pode
acompanhar a saúde do serviço no Portal Azure. Para mais informações, consulte a saúde do serviço track.
Monitorize a sua aplicação
Esta opção permite-lhe descobrir se a sua aplicação está a ter algum problema. Na lâmina da sua aplicação, clique
nos pedidos e erros em azulejo. A lâmina métrica irá mostrar-lhe todas as métricas que pode adicionar.
Algumas das métricas que pode querer monitorizar para a sua aplicação são
Conjunto de trabalho de memória média
Tempo médio de resposta
Hora do CPU
Conjunto de trabalho de memória
Pedidos
Para obter mais informações, consulte:

Monitorize aplicativos no Azure App Service
Receber notificações de alerta
2. Recolher dados
Utilize a ferramenta de diagnóstico
O App Service proporciona uma experiência inteligente e interativa para o ajudar a resolver problemas na sua
aplicação sem necessidade de configuração. Quando tiver problemas com a sua aplicação, a ferramenta de
diagnóstico irá indicar o que é errado guiá-lo para as informações certas para resolver e resolver o problema de
forma mais fácil e rápida.
Para aceder aos diagnósticos do Serviço de Aplicações, navegue para a sua app app App Service ou App Service
Environment no portal Azure. Na navegação à esquerda, clique no Diagnóstico e resolva problemas.
Use a consola Kudu Debug
O App Service vem com uma consola de depuração que podes usar para depurar, explorar, carregar ficheiros, bem
como pontos finais JSON para obter informações sobre o teu ambiente. Isto chama-se Consola Kudu ou O Painel
de Instrumentos SCM para a sua aplicação.
Pode aceder a este dashboard indo ao link https:// O nome da sua < aplicação>.scm.azurewebsites.net/ .
Algumas das coisas que Kudu fornece são:
configurações de ambiente para a sua aplicação
fluxo de log
despejo de diagnóstico
depurar consola na qual pode executar cmdlets Powershell e comandos básicos DOS.
Outra característica útil da Kudu é que, caso a sua aplicação esteja a lançar exceções de primeira oportunidade,
pode usar a Kudu e a ferramenta SysInternals Procdump para criar despejos de memória. Estes despejos de
memória são instantâneos do processo e podem muitas vezes ajudá-lo a resolver problemas mais complicados
com a sua app.
Para obter mais informações sobre as funcionalidades disponíveis em Kudu, consulte as ferramentas online da
Azure Websites que deve conhecer.
Dimensione a aplicação
No Azure App Service, para maior desempenho e produção, pode ajustar a escala em que está a executar a sua
aplicação. O escalonamento de uma aplicação envolve duas ações relacionadas: alterar o seu plano de Serviço de
Aplicações para um nível de preços mais elevado e configurar determinadas definições depois de ter mudado para
o nível de preços mais elevado.
Para obter mais informações sobre o dimensionamento, consulte Scale uma aplicação no Azure App Service.
Além disso, pode optar por executar a sua aplicação em mais de um caso. Isto não só lhe proporciona mais
capacidade de processamento, como também lhe dá alguma tolerância à falha. Se o processo se der em curso
numa instância, a outra instância continuará a servir os pedidos.
Pode configurar a escala para ser manual ou automática.
Use AutoHeal
O AutoHeal recicla o processo de trabalhador para a sua aplicação com base nas definições que escolhe (como
alterações de configuração, pedidos, limites baseados na memória ou o tempo necessário para executar um
pedido). Na maior parte do tempo, reciclar o processo é a forma mais rápida de recuperar de um problema.
Embora possa sempre reiniciar a aplicação diretamente dentro do Portal Azure, o AutoHeal fá-lo-á
automaticamente para si. Tudo o que precisa fazer é adicionar alguns gatilhos na web raiz.config para a sua
aplicação. Note que estas definições funcionariam da mesma forma, mesmo que a sua aplicação não seja uma .NET.
Para obter mais informações, consulte os Web Sites Azure de auto-cura.
Reiniciar a aplicação
Esta é muitas vezes a forma mais simples de recuperar de problemas pontuais. No Portal Azure, na lâmina da sua
aplicação, tem as opções para parar ou reiniciar a sua aplicação.
Também pode gerir a sua aplicação usando a Azure Powershell. Para obter mais informações, veja Using Azure
PowerShell with Azure Resource Manager (Utilizar o Azure PowerShell com o Azure Resource Manager).
Resolução de problemas problemas de desempenho
de aplicações lentas no Azure App Service
Este artigo ajuda-o a resolver problemas de desempenho de aplicações lentas no Azure App Service.
Se precisar de mais ajuda em qualquer ponto deste artigo, pode contactar os especialistas da Azure nos fóruns
msdn azure e nos fóruns Stack Overflow. Em alternativa, também pode apresentar um incidente de suporte Azure.
Vá ao site de suporte do Azure e clique em Obter Supor te.
Sintoma
Quando navega na aplicação, as páginas carregam lentamente e às vezes o tempo limite.
Causa
Este problema é muitas vezes causado por problemas de nível de aplicação, tais como:
pedidos de rede demorando muito tempo
código de aplicação ou consultas de base de dados sendo ineficientes
aplicação usando alta memória/CPU
aplicação crashing devido a uma exceção
Passos de resolução de problemas

A resolução de problemas pode ser dividida em três tarefas distintas, por ordem sequencial:
2. Recolher dados
O Serviço de Aplicações oferece-lhe várias opções em cada passo.
Saúde do Serviço de Rastreio
O Microsoft Azure divulga cada vez que há uma interrupção de serviço ou degradação de desempenho. Pode
acompanhar a saúde do serviço no portal Azure. Para mais informações, consulte a saúde do serviço track.
Monitorize a sua aplicação
Esta opção permite-lhe descobrir se a sua aplicação está a ter algum problema. Na lâmina da sua aplicação, clique
nos pedidos e erros em azulejo. A lâmina métrica mostra-lhe todas as métricas que pode adicionar.
Algumas das métricas que pode querer monitorizar para a sua aplicação são
Conjunto de trabalho de memória média
Tempo médio de resposta
Hora do CPU
Conjunto de trabalho de memória
Pedidos
Para obter mais informações, consulte:
Monitorize aplicativos no Azure App Service
Receber notificações de alerta
Monitorar o estado do ponto final da web
Se estiver a executar a sua aplicação no nível de preços Standard, o App Service permite-lhe monitorizar dois
pontos finais de três localizações geográficas.
A monitorização do ponto final configura testes web a partir de locais geo-distribuídos que testam o tempo de
resposta e o tempo de paragem dos URLs web. O teste executa uma operação HTTP GET no URL web para
determinar o tempo de resposta e o tempo de funcionamento de cada local. Cada local configurado realiza um
teste a cada cinco minutos.
O tempo de utilização é monitorizado utilizando códigos de resposta HTTP e o tempo de resposta é medido em
milissegundos. Um teste de monitorização falha se o código de resposta HTTP for superior ou igual a 400 ou se a
resposta demorar mais de 30 segundos. Considera-se disponível um ponto final se os seus testes de monitorização
forem bem sucedidos em todos os locais especificados.
Para o configurar, consulte as aplicações do Monitor no Azure App Service.
Além disso, consulte Keep Azure Web Sites up plus Endpoint Monitoring - com Stefan Schackow para um vídeo na
monitorização do ponto final.
Monitorização do desempenho da aplicação utilizando extensões
Também pode monitorizar o desempenho da sua aplicação utilizando uma extensão do site.
Cada aplicação do Serviço de Aplicações fornece um ponto final de gestão extensível que lhe permite usar um
poderoso conjunto de ferramentas implementadas como extensões do site. As extensões incluem:
Editores de código fonte como Azure DevOps.
Ferramentas de gestão para recursos conectados, como uma base de dados MySQL ligada a uma aplicação.
Azure Application Insights é uma extensão do site de monitorização de desempenho que também está disponível.
Para utilizar o Application Insights, reconstrói o seu código com um SDK. Também pode instalar uma extensão que
dá acesso a dados adicionais. O SDK permite-lhe escrever código para monitorizar o uso e desempenho da sua
aplicação com mais detalhes. Para obter mais informações, consulte o desempenho do Monitor em aplicações web.
2. Recolher dados
O Serviço de Aplicações fornece funcionalidade de diagnóstico para registar informações tanto do servidor web
como da aplicação web. A informação é separada em diagnósticos de servidores web e diagnósticos de aplicações.
Ativar diagnósticos de servidor web
Pode ativar ou desativar os seguintes tipos de registos:
Registo de erros detalhados - Informações detalhadas de erro para códigos de estado HTTP que indicam
uma falha (código de estado 400 ou superior). Isto pode conter informações que podem ajudar a determinar
por que o servidor devolveu o código de erro.
Rastreio de pedidos falhados - Informações detalhadas sobre pedidos falhados, incluindo um traço dos
componentes IIS utilizados para processar o pedido e o tempo de cada componente. Isto pode ser útil se estiver
a tentar melhorar o desempenho da aplicação ou isolar o que está a causar um erro http específico.
Início de Sessão do Ser vidor Web - Informações sobre transações HTTP utilizando o formato de ficheiro de
registo estendido W3C. Isto é útil para determinar as métricas globais das aplicações, como o número de
pedidos tratados ou quantos pedidos são de um endereço IP específico.
Ativar diagnósticos de aplicações
Existem várias opções para recolher dados de desempenho da aplicação a partir do App Service, perfilar a sua
aplicação ao vivo a partir do Visual Studio ou modificar o seu código de aplicação para registar mais informações e
vestígios. Pode escolher as opções com base no acesso que tem à aplicação e no que observou a partir das
ferramentas de monitorização.
U se o p e r fi l d e i n si g h t s d e a p l i c a ç õ e s
Pode ativar o Profiler Application Insights para começar a capturar vestígios de desempenho detalhados. Podes
aceder a vestígios capturados até há cinco dias, quando precisas de investigar que os problemas aconteceram no
passado. Pode escolher esta opção desde que tenha acesso ao recurso Application Insights da aplicação no portal
Azure.
O Application Insights Profiler fornece estatísticas sobre o tempo de resposta para cada chamada web e vestígios
que indicam qual a linha de código que causou as respostas lentas. Por vezes, a aplicação Do Serviço de Aplicações
é lenta porque determinado código não está escrito de forma performante. Exemplos incluem código sequencial
que pode ser executado em contenções de bloqueio de base de dados paralelas e não-existentes. A remoção destes
estrangulamentos no código aumenta o desempenho da aplicação, mas são difíceis de detetar sem configurar
vestígios e registos elaborados. Os vestígios recolhidos pelo Application Insights Profiler ajudam a identificar as
linhas de código que abrandam a aplicação e superam este desafio para aplicações do App Service.
Para obter mais informações, consulte Profiling aplicações ao vivo no Azure App Service com Application Insights.
U se p e r fi s r e m o t o s
No Azure App Service, aplicações web, aplicações API, back ends móveis e WebJobs podem ser perfilado
remotamente. Escolha esta opção se tiver acesso ao recurso da aplicação e souber reproduzir o problema, ou se
souber o intervalo de tempo exato que o problema de desempenho acontece.
O Perfil Remoto é útil se o uso do CPU do processo for elevado e o seu processo estiver a funcionar mais devagar
do que o esperado, ou se a latência dos pedidos HTTP for superior ao normal, pode perfilar remotamente o seu
processo e obter as pilhas de chamadas de amostragem do CPU para analisar a atividade do processo e codificar
caminhos quentes.
Para obter mais informações, consulte o suporte de perfis remotos no Serviço de Aplicações Azure.
C o n fi g u r a r o s v e st í g i o s d e d i a g n ó st i c o m a n u a l m e n t e
Se tiver acesso ao código fonte da aplicação web, o diagnóstico de aplicação permite-lhe capturar informações
produzidas por uma aplicação web. ASP.NET aplicações podem usar a System.Diagnostics.Trace classe para
registar informações no registo de diagnósticos de aplicação. No entanto, é necessário alterar o código e recolocar
a sua aplicação. Este método é recomendado se a sua aplicação estiver a funcionar num ambiente de teste.
Para obter instruções detalhadas sobre como configurar a sua aplicação para registo de registo, consulte Ativar o
registo de diagnósticos de aplicações no Azure App Service.
Utilize a ferramenta de diagnóstico
O App Service proporciona uma experiência inteligente e interativa para o ajudar a resolver problemas na sua
aplicação sem necessidade de configuração. Quando tiver problemas com a sua aplicação, a ferramenta de
diagnóstico irá indicar o que é errado guiá-lo para as informações certas para resolver e resolver o problema de
forma mais fácil e rápida.
Para aceder aos diagnósticos do Serviço de Aplicações, navegue para a sua app app App Service ou App Service
Environment no portal Azure. Na navegação à esquerda, clique no Diagnóstico e resolva problemas.
Use a consola Kudu Debug
O App Service vem com uma consola de depuração que podes usar para depurar, explorar, carregar ficheiros, bem
como pontos finais JSON para obter informações sobre o teu ambiente. Esta consola chama-se Consola Kudu ou o
Painel de Instrumentos SCM para a sua aplicação.
Pode aceder a este dashboard indo ao link https:// O nome da sua < aplicação>.scm.azurewebsites.net/ .
Algumas das coisas que Kudu fornece são:
configurações de ambiente para a sua aplicação
fluxo de log
despejo de diagnóstico
depurar consola na qual pode executar cmdlets Powershell e comandos básicos DOS.
Outra característica útil da Kudu é que, caso a sua aplicação esteja a lançar exceções de primeira oportunidade,
pode usar a Kudu e a ferramenta SysInternals Procdump para criar despejos de memória. Estes despejos de
memória são instantâneos do processo e podem muitas vezes ajudá-lo a resolver problemas mais complicados
com a sua app.
Para obter mais informações sobre as funcionalidades disponíveis em Kudu, consulte as ferramentas Azure
DevOps que deve conhecer.
Dimensione a aplicação
No Azure App Service, para maior desempenho e produção, pode ajustar a escala em que está a executar a sua
aplicação. O escalonamento de uma aplicação envolve duas ações relacionadas: alterar o seu plano de Serviço de
Aplicações para um nível de preços mais elevado e configurar determinadas definições depois de ter mudado para
o nível de preços mais elevado.
Para obter mais informações sobre o dimensionamento, consulte Scale uma aplicação no Azure App Service.
Além disso, pode optar por executar a sua aplicação em mais de um caso. A escala não só lhe proporciona mais
capacidade de processamento, como também lhe dá alguma tolerância à falha. Se o processo se der em curso
numa instância, as outras instâncias continuam a servir pedidos.
Pode configurar a escala para ser manual ou automática.
Use AutoHeal
O AutoHeal recicla o processo de trabalhador para a sua aplicação com base nas definições que escolhe (como
alterações de configuração, pedidos, limites baseados na memória ou o tempo necessário para executar um
pedido). Na maior parte do tempo, reciclar o processo é a forma mais rápida de recuperar de um problema.
Embora possa sempre reiniciar a aplicação diretamente dentro do portal Azure, o AutoHeal fá-la automaticamente
para si. Tudo o que precisa fazer é adicionar alguns gatilhos na web raiz.config para a sua aplicação. Estas
definições funcionariam da mesma forma, mesmo que a sua aplicação não seja uma aplicação .NET.
Para obter mais informações, consulte os Web Sites Azure de auto-cura.
Reiniciar a aplicação
Reiniciar é muitas vezes a forma mais simples de recuperar de problemas únicos. No portal Azure, na lâmina da
sua aplicação, tem as opções para parar ou reiniciar a sua aplicação.
Também pode gerir a sua aplicação usando a Azure Powershell. Para obter mais informações, veja Using Azure
PowerShell with Azure Resource Manager (Utilizar o Azure PowerShell com o Azure Resource Manager).
Problemas de domínio e problemas de certificado
TLS/SSL no Serviço de Aplicações Azure
Este artigo lista problemas comuns que poderá encontrar quando configura rumar um certificado de domínio ou
TLS/SSL para as suas aplicações web no Azure App Service. Descreve também possíveis causas e soluções para
estes problemas.
Se precisar de mais ajuda em qualquer ponto deste artigo, pode contactar os especialistas do Azure nos fóruns
mSDN e Stack Overflow. Em alternativa, pode apresentar um incidente de apoio ao Azure. Vá ao site de suporte do
Azure e selecione Obter Supor te .
NOTE
Problemas de certificado
Não é possível adicionar um certificado TLS/SSL vinculativo a uma aplicação
Sintoma
Quando adiciona uma ligação TLS, recebe a seguinte mensagem de erro:
"Não adicionou a ligação SSL. Não é possível definir certificado para VIP existente porque outro VIP já usa esse
certificado."
Causa
Este problema pode ocorrer se tiver várias ligações SSL baseadas em IP para o mesmo endereço IP em várias
aplicações. Por exemplo, a app A tem um SSL baseado em IP com um certificado antigo. A App B tem um SSL
baseado em IP com um novo certificado para o mesmo endereço IP. Ao atualizar a aplicação TLS vinculando-se com
o novo certificado, falha com este erro porque o mesmo endereço IP está a ser usado para outra aplicação.
Solução
Para corrigir este problema, utilize um dos seguintes métodos:
Elimine a ligação SSL baseada em IP na aplicação que utiliza o certificado antigo.
Crie uma nova ligação SSL baseada em IP que utilize o novo certificado.
Não pode apagar um certificado
Sintoma
Quando tenta apagar um certificado, recebe a seguinte mensagem de erro:
"Não pode ndo apagar o certificado porque está atualmente a ser utilizado numa ligação TLS/SSL. A ligação TLS
deve ser removida antes de poder eliminar o certificado."
Causa
Este problema pode ocorrer se outra aplicação usar o certificado.
Solução
Remova a ligação TLS para esse certificado das aplicações. Em seguida, tente apagar o certificado. Se ainda não
conseguir apagar o certificado, limpe a cache do navegador de Internet e abra o portal Azure numa nova janela do
navegador. Em seguida, tente apagar o certificado.
Não pode comprar um certificado de Serviço de Aplicações
Sintoma
Não é possível comprar um certificado de Serviço de Aplicações Azure no portal Azure.
Causa e solução
Este problema pode ocorrer por qualquer uma das seguintes razões:
O plano de Serviço de Aplicações é Gratuito ou Partilhado. Estes níveis de preços não suportam TLS.
Solução : Atualize o plano do Serviço de Aplicações para a App para Standard.
A subscrição não tem um cartão de crédito válido.
Solução : Adicione um cartão de crédito válido à sua subscrição.
A oferta de subscrição não suporta a aquisição de um certificado de Serviço de Aplicações, como o
Microsoft Student.
Solução : Atualize a sua subscrição.
A subscrição atingiu o limite de compras que são permitidas numa subscrição.
Solução : Os certificados do Serviço de Aplicações têm um limite de 10 compras de certificados para os
tipos de subscrição Pay-As-You-Go e EA. Para outros tipos de subscrição, o limite é 3. Para aumentar o limite,
contacte o suporte azure.
O certificado do Serviço de Aplicações foi marcado como fraude. Recebeu a seguinte mensagem de erro: "O
seu certificado foi sinalizado por possível fraude. O pedido está atualmente a ser analisado. Se o certificado
não for utilizável dentro de 24 horas, contacte o Suporte Azure."
Solução : Se o certificado estiver marcado como fraude e não for resolvido após 24 horas, siga estes passos:
1. Inicie sessão no portal do Azure.
2. Vá aos Certificados de Serviço de Aplicações e selecione o certificado.
3. Selecione passo de configuração > do certificado2: Verifique > a verificação do domínio . Este
passo envia um aviso de e-mail ao fornecedor de certificados Azure para resolver o problema.
Problemas de domínio personalizados

Um domínio personalizado devolve um erro de 404
Sintoma
Quando navega no site utilizando o nome de domínio personalizado, recebe a seguinte mensagem de erro:
"Error 404-Web app não encontrado."
Causa e solução
Causa 1
O domínio personalizado que configuraste está a faltar um CNAME ou um disco.
Solução para o motivo 1
Se tiver adicionado um disco A, certifique-se de que um disco TXT também é adicionado. Para mais
informações, consulte Criar o registo A.
Se não tiver de utilizar o domínio raiz para a sua aplicação, recomendamos que utilize um disco CNAME em vez
de um disco A.
Não use um disco CNAME e um disco A para o mesmo domínio. Esta questão pode causar um conflito e
impedir que o domínio seja resolvido.
Causa 2
O navegador de internet ainda pode estar a gravar o antigo endereço IP para o seu domínio.
Solução para a Causa 2
Limpe o navegador. Para dispositivos Windows, pode ipconfig /flushdns executar o comando . Utilize
WhatsmyDNS.net para verificar se o seu domínio aponta para o endereço IP da aplicação.
Não se pode adicionar um subdomínio
Sintoma
Não é possível adicionar um novo nome de anfitrião a uma aplicação para atribuir um subdomínio.
Solução
Consulte o administrador de subscrição para se certificar de que tem permissões para adicionar um nome de
anfitrião à aplicação.
Se precisar de mais subdomínios, recomendamos que altere o domínio para o Serviço de Nome de Domínio
Azure (DNS). Ao utilizar o Azure DNS, pode adicionar 500 nomes de anfitriões à sua aplicação. Para mais
informações, consulte Adicionar um subdomínio.
DNS não pode ser resolvido
Sintoma
Recebeu a seguinte mensagem de erro:
"O registo do DNS não pôde ser localizado."
Causa
Este problema ocorre por uma das seguintes razões:
O período de vida (TTL) não expirou. Verifique a configuração DNS para determinar o valor TTL e, em seguida,
aguarde que o período expire.
A configuração DNS está incorreta.
Solução
Espere 48 horas para que este problema se resolva sozinho.
Se conseguir alterar a definição de TTL na sua configuração DNS, altere o valor para 5 minutos para ver se isto
resolve o problema.
Utilize WhatsmyDNS.net para verificar se o seu domínio aponta para o endereço IP da aplicação. Se não o fizer,
configure o registo A para o endereço IP correto da aplicação.
Precisa restaurar um domínio eliminado
Sintoma
O seu domínio já não é visível no portal Azure.
Causa
O proprietário da subscrição pode ter acidentalmente apagado o domínio.
Solução
Se o seu domínio foi apagado há menos de sete dias, o domínio ainda não iniciou o processo de eliminação. Neste
caso, pode voltar a comprar o mesmo domínio no portal Azure sob a mesma subscrição. (Certifique-se de que
escreve o nome de domínio exato na caixa de pesquisa.) Não voltará a ser cobrado por este domínio. Se o domínio
foi apagado há mais de sete dias, contacte o suporte azure para ajudar na restauração do domínio.
Problemas de domínio
Comprou um certificado TLS/SSL para o domínio errado
Sintoma
Comprou um certificado de Serviço de Aplicações para o domínio errado. Não é possível atualizar o certificado
para utilizar o domínio correto.
Solução
Apague esse certificado e, em seguida, compre um novo certificado.
Se o certificado atual que usa o domínio errado estiver no estado "Emitido", também será cobrado para esse
certificado. Os certificados do Serviço de Aplicações não são reembolsáveis, mas pode contactar o suporte do
Azure para ver se existem outras opções.
Um certificado de Serviço de Aplicações foi renovado, mas a aplicação mostra o antigo certificado
Sintoma
O certificado de Serviço de Aplicações foi renovado, mas a aplicação que utiliza o certificado de Serviço de
Aplicações ainda está a usar o certificado antigo. Além disso, recebeu um aviso de que o protocolo HTTPS é
necessário.
Causa
O Serviço de Aplicações sincroniza automaticamente o seu certificado dentro de 48 horas. Quando roda ou atualiza
um certificado, por vezes o pedido ainda está a recuperar o certificado antigo e não o certificado recém-atualizado.
A razão é que o trabalho para sincronizar o recurso de certificado ainda não funcionou. Clique em Sync. A operação
de sincronização atualiza automaticamente as encadernações do nome de anfitrião para o certificado no Serviço de
Aplicações sem causar qualquer inatividade nas suas apps.
Solução
Pode forçar uma sincronização do certificado:
1. Inicie sessão no portal do Azure. Selecione Certificados de Serviço de Aplicações e, em seguida, selecione o
certificado.
2. Selecione Rekey e Sync, e, em seguida, selecione Sync . A sincronização leva algum tempo para terminar.
3. Quando a sincronização estiver concluída, vê a seguinte notificação: "Atualizou com sucesso todos os recursos
com o certificado mais recente."
A verificação de domínio não está a funcionar
Sintoma
O certificado do Serviço de Aplicações requer verificação de domínio antes de o certificado estar pronto a ser
utilizado. Quando selecionar Verificar, o processo falha.
Solução
Verifique manualmente o seu domínio adicionando um registo TXT:
1. Vá ao fornecedor do Serviço de Nomes de Domínio (DNS) que acolhe o seu nome de domínio.
2. Adicione um registo TXT para o seu domínio que utiliza o valor do símbolo de domínio que é mostrado no
portal Azure.
Aguarde alguns minutos para que a propagação do DNS se escorra e, em seguida, selecione o botão Refresh para
desencadear a verificação.
Como alternativa, pode utilizar o método da página web HTML para verificar manualmente o seu domínio. Este
método permite à autoridade do certificado confirmar a propriedade do domínio do domínio para o que o
certificado é emitido.
1. Crie um ficheiro HTML que se chame {domain verification token}.html. O conteúdo deste ficheiro deve ser o
valor da ficha de verificação de domínio.
2. Faça upload deste ficheiro na raiz do servidor web que está hospedando o seu domínio.
3. Selecione Refresh para verificar o estado do certificado. Pode levar alguns minutos para a verificação terminar.
Por exemplo, se estiver a comprar um certificado padrão para azure.com com o token de
https://azure.com/1234abcd.html verificação de domínio 1234abcd, um pedido web feito deve devolver 1234abcd.
IMPORTANT
Uma ordem de certificado tem apenas 15 dias para completar a operação de verificação de domínio. Após 15 dias, a
autoridade do certificado nega a certidão e não é cobrado pelo certificado. Nesta situação, apague este certificado e tente
novamente.
Não se pode comprar um domínio

Sintoma
Não é possível comprar um domínio do Serviço de Aplicações no portal Azure.
Causa e solução
Não existem cartões de crédito na subscrição do Azure ou o cartão de crédito é inválido.
Solução : Adicione um cartão de crédito válido à sua subscrição.
Não é o proprietário da subscrição, pelo que não tem permissão para comprar um domínio.
Solução : Atribuir a função proprietário à sua conta. Ou contacte o administrador de subscrição para obter
permissão para adquirir um domínio.
Atingiu o limite de compra de domínios da subscrição. O limite atual é 20.
Solução : Para solicitar um aumento do limite, contacte o suporte azure.
O tipo de subscrição do Azure não suporta a compra de um domínio do Serviço de Aplicações.
Solução : Atualize a subscrição do Azure para outro tipo de subscrição, como uma subscrição Pay-As-You-
Go.
Não pode adicionar um nome de anfitrião a uma aplicação
Sintoma
Quando adiciona um nome de anfitrião, o processo não valida e verifica o domínio.
Causa
Não tem permissão para adicionar um nome de anfitrião.
Solução : Peça ao administrador de subscrição que lhe dê permissão para adicionar um nome de anfitrião.
A sua propriedade de domínio não pôde ser verificada.
Solução : Verifique se o seu registo CNAME ou A está configurado corretamente. Para mapear um domínio
personalizado para uma aplicação, crie um disco CNAME ou um disco A. Se pretender utilizar um domínio
raiz, deve utilizar registos A e TXT:
T IP O DE REGISTO A N F IT RIÃ O A P O N TA R PA RA
A @ Endereço IP para uma aplicação
TXT @ <app-name>.azurewebsites.net
CNAME www <app-name>.azurewebsites.net

FAQ
Tenho de configurar o meu domínio personalizado para o meu website assim que o comprar?
Ao adquirir um domínio no portal Azure, a aplicação do Serviço de Aplicações é configurada automaticamente para
utilizar esse domínio personalizado. Não tens de dar passos adicionais. Para mais informações, assista a Self Help
do Serviço de Aplicações Azure: Adicione um nome de domínio personalizado no Canal9.
Posso usar um domínio comprado no por tal Azure para apontar para um VM Azure?
Sim, pode apontar o domínio para um VM. Para obter mais informações, veja Utilizar o DNS do Azure para oferecer
definições de domínio personalizado para um serviço do Azure.
O meu domínio é hospedado pelo GoDaddy ou pelo Azure DNS?
Os domínios do serviço de aplicações usam o GoDaddy para o registo de domínioe o Azure DNS para acolher os
domínios.
Tenho renovação automática ativada, mas ainda recebi um aviso de renovação para o meu domínio
por e-mail. O que devo fazer?
Se tiver uma renovação automática ativada, não precisa de tomar qualquer medida. O e-mail de aviso é fornecido
para informá-lo de que o domínio está perto de expirar e para renovar manualmente se não estiver ativado a
renovação automática.
Vou ser cobrado pelo Azure DNS que acolhe o meu domínio?
O custo inicial da compra de domínio aplica-se apenas ao registo de domínio. Além do custo de registo, existem
encargos incorridos para o DNS Azure com base na sua utilização. Para mais informações, consulte os preços do
DNS azure para obter mais detalhes.
Comprei o meu domínio mais cedo no por tal Azure e quero mudar-me do GoDaddy para o anfitrião
do DNS Azure. Como posso fazer isto?
Não é obrigatório migrar para o dNS azure hospedado. Se quiser migrar para o Azure DNS, a experiência de gestão
de domínios no portal Azure sobre fornece informações sobre as etapas necessárias para se deslocar para O DNS
Azure. Se o domínio foi adquirido através do App Service, a migração do GoDaddy hospedado para o DNS Azure é
um procedimento relativamente perfeito.
Gostaria de comprar o meu domínio no Domínio do Ser viço de Aplicações, mas posso hospedar o
meu domínio no GoDaddy em vez do Azure DNS?
A partir de 24 de julho de 2017, os domínios do App Service adquiridos no portal estão hospedados no Azure
DNS. Se preferir utilizar um fornecedor de hospedagem diferente, deve ir ao seu website para obter uma solução
de hospedagem de domínio.
Tenho de pagar a proteção da privacidade pelo meu domínio?
Ao adquirir um domínio através do portal Azure, pode optar por adicionar privacidade sem custos adicionais. Este é
um dos benefícios de comprar o seu domínio através do Azure App Service.
Se eu decidir que não quero mais o meu domínio, posso ter o meu dinheiro de volta?
Ao comprar um domínio, não é cobrado por um período de cinco dias, período durante o qual pode decidir que
não quer o domínio. Se decidir que não quer o domínio dentro desse período de cinco dias, não será cobrado. (.os
domínios do Reino Unido são uma exceção a isto. Se comprar um domínio .uk, é cobrado imediatamente e não
pode ser reembolsado.)
Posso usar o domínio em outra aplicação do Ser viço de Aplicações Azure na minha subscrição?
Sim. Ao aceder aos Domínios Personalizados e à lâmina TLS no portal Azure, vê os domínios que adquiriu. Pode
configurar a sua aplicação para utilizar qualquer um desses domínios.
Posso transferir um domínio de uma subscrição para outra subscrição?
Pode mover um domínio para outro grupo de subscrição/recursos utilizando o cmdlet Move-AzResource
PowerShell.
Como posso gerir o meu domínio personalizado se não tenho atualmente uma aplicação azure App
Ser vice?
Pode gerir o seu domínio mesmo que não tenha uma Aplicação Web do Serviço de Aplicações. O domínio pode ser
utilizado para serviços Azure como máquina virtual, armazenamento etc. Se pretende utilizar o domínio para
aplicações web do serviço de aplicações, então precisa de incluir uma Aplicação Web que não esteja no plano de
Serviço de Aplicações Gratuitos para ligar o domínio à sua aplicação web.
Posso mover uma aplicação web com um domínio personalizado para outra subscrição ou de App
Ser vice Environment v1 para V2?
Sim, pode mover a sua aplicação web através de subscrições. Siga a orientação em Como movimentar recursos em
Azure. Existem algumas limitações ao mover a aplicação web. Para mais informações, consulte Limitações para
movimentar recursosdo Serviço de Aplicações .
Depois de mover a aplicação web, as ligações de nome do anfitrião dos domínios dentro da definição de domínios
personalizados devem permanecer as mesmas. Não são necessários passos adicionais para configurar as
encadernações do nome do anfitrião.
Perguntas de desempenho de aplicações para
aplicações web em Azure
NOTE
Algumas das diretrizes abaixo só podem funcionar em Serviços de Aplicações Windows ou Linux. Por exemplo, os Serviços de
Aplicações Linux funcionam em modo de 64 bits por padrão.
Este artigo tem respostas a perguntas frequentes (PERGUNTAS) sobre problemas de desempenho de aplicações
para a funcionalidade de Aplicações Web do Azure App Service.
Se o seu problema azure não for abordado neste artigo, visite os fóruns do Azure sobre mSDN e Stack Overflow.
Pode publicar o seu problema nestes fóruns, ou publicar @AzureSupport no Twitter. Também pode apresentar um
pedido de apoio azure. Para submeter um pedido de apoio, na página de suporte do Azure, selecione Obter
supor te .
Porque é que a minha aplicação é lenta?

Vários fatores podem contribuir para um desempenho lento da aplicação. Para obter passos detalhados de
resolução de problemas, consulte o desempenho lento da aplicação web troubleshoot.
Como posso resolver um cenário de consumo de CPU?

Em alguns cenários elevados de consumo de CPU, a sua aplicação pode realmente necessitar de mais recursos
informáticos.Nesse caso, considere a escala para um nível de serviço mais elevado para que a aplicação obtenha
todos os recursos de que necessita. Outras vezes, o elevado consumo de CPU pode ser causado por um mau ciclo
ou por uma prática de codificação. Obter informações sobre o que está a desencadear o aumento do consumo de
CPU é um processo em duas partes. Primeiro, crie um depósito de processo, e depois analise o despejo do
processo. Para mais informações, consulte Capturar e analisar um ficheiro de despejo para um alto consumo de
CPU para Aplicações Web.
Como posso resolver um cenário de alto consumo de memória?

Em alguns cenários de alto consumo de memória, a sua aplicação pode realmente necessitar de mais recursos
informáticos.Nesse caso, considere a escala para um nível de serviço mais elevado para que a aplicação obtenha
todos os recursos de que necessita. Outras vezes, um inseto no código pode causar uma fuga de memória. Uma
prática de codificação também pode aumentar o consumo de memória.Obter informações sobre o que está a
desencadear um elevado consumo de memória é um processo em duas partes. Primeiro, crie um depósito de
processo, e depois analise o despejo do processo. O Diagnosticizador de Acidentes da Galeria de Extensão do Sítio
Azure pode executar eficazmente estes dois passos. Para mais informações, consulte Capturar e analisar um
ficheiro de despejo para alta memória intermitente para Aplicações Web.
Como automatizar aplicações web do App Service utilizando o

PowerShell?
Pode utilizar cmdlets PowerShell para gerir e manter aplicações web do App Service. No nosso blog post
Aplicações web Automate hospedadas no Azure App Service utilizando o PowerShell,descrevemos como usar
cmdlets PowerShell baseados em Recursos Azure para automatizar tarefas comuns. O post do blog também tem
código de amostra para várias tarefas de gestão de aplicações web. Para descrições e sintaxe para todas as
aplicações web do App Service, consulte Az.Websites.
Como vejo os registos de eventos da minha aplicação web?

Para ver os registos de eventos da sua aplicação web:
1. Inscreva-se no seu https://*yourwebsitename*.scm.azurewebsites.net site kudu ().
2. No menu, selecione Debug Console > CMD .
3. Selecione a pasta LogFiles.
4. Para ver os registos de eventos, selecione o ícone do lápis ao lado do eventlog.xml .
5. Para descarregar os registos, execute Save-AzureWebSiteLog -Name webappname o cmdlet PowerShell .
Como posso capturar um despejo de memória em modo utilizador da

minha aplicação web?
Para capturar um despejo de memória em modo utilizador da sua aplicação web:
2. Selecione o menu Process Explorer.
3. Clique no processo w3wp.exe ou no seu processo WebJob.
4. Selecione Descarregar depósito completo de > memória .
Como vejo informações de nível de processo para a minha aplicação

web?
Tem duas opções para visualizar informações de nível de processo para a sua aplicação web:
No portal do Azure:
1. Abra o Process Explorer para a aplicação web.
2. Para ver os detalhes, selecione o processo w3wp.exe.
Na consola kudu:
2. Selecione o menu Process Explorer.
3. Para o processo w3wp.exe, selecione Propriedades .
Quando navego na minha aplicação, vejo "Error 403 - Esta aplicação

web é interrompida." Como posso resolver isto?
Três condições podem causar este erro:
A aplicação web atingiu um limite de faturação e o seu site foi desativado.
A aplicação web foi interrompida no portal.
A aplicação web atingiu um limite de quota de recursos que pode aplicar-se a um plano de serviço à escala livre
ou partilhada.
Para ver o que está a causar o erro e resolver o problema, siga os passos nas Aplicações Web: "Error 403 – Esta
aplicação web está parada".
Onde posso aprender mais sobre quotas e limites para vários planos de
Serviço de Aplicações?
Para obter informações sobre quotas e limites, consulte os limites do Serviço de Aplicações.
Como reduzi o tempo de resposta para o primeiro pedido após o

tempo de inatividade?
Por padrão, as aplicações web são descarregadas se ficarem inativas por um determinado período de tempo. Desta
forma, o sistema pode conservar recursos. A desvantagem é que a resposta ao primeiro pedido após o
descarregamento da aplicação web é mais longa, para permitir que a aplicação web carregue e comece a servir
respostas. Nos planos de serviço Basic e Standard, pode ligar a definição Always On para manter a aplicação
sempre carregada. Isto elimina tempos de carga mais longos após a aplicação estar inativa. Para alterar a definição
sempre em cima:
1. No portal Azure, vá à sua aplicação web.
2. Configuração selecione
3. Selecione as definições gerais .
4. Para sempre ligado, selecione On .
Como ligo o pedido falhado?

Para ativar o rastreio de pedido falhado:
2. Selecione todos osregistos de diagnóstico de definições > .
3. Para rastreio de pedido falhado, selecione On .
5. Na lâmina da aplicação web, selecione Tools .
6. Selecione Estúdio Visual Online .
7. Se a definição não estiver ligado, selecione On .
8. Selecione Go .
9. Selecione Web.config .
10. No system.webServer, adicione esta configuração (para capturar um URL específico):
<system.webServer>
<tracing> <traceFailedRequests>
<remove path="*api*" />
<add path="*api*">
<traceAreas>
<add provider="ASP" verbosity="Verbose" />
<add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
<add provider="ISAPI Extension" verbosity="Verbose" />
<add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,
Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
</traceAreas>
<failureDefinitions statusCodes="200-999" />
</add> </traceFailedRequests>
</tracing>
11. Para resolver problemas de desempenho lento, adicione esta configuração (se o pedido de captura estiver a
demorar mais de 30 segundos):
<system.webServer>
<tracing> <traceFailedRequests>
<remove path="*" />
<add path="*">
<traceAreas> <add provider="ASP" verbosity="Verbose" />
<add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
<add provider="ISAPI Extension" verbosity="Verbose" />
<add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,
Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
</traceAreas>
<failureDefinitions timeTaken="00:00:30" statusCodes="200-999" />
</add> </traceFailedRequests>
</tracing>
12. Para descarregar os vestígios de pedido falhados, no portal,vá ao seu site.

13. Selecione Ferramentas > Kudu > Go .
14. No menu, selecione Debug Console > CMD .
15. Selecione a pasta LogFiles e, em seguida, selecione a pasta com um nome que começa com W3SVC .
16. Para ver o ficheiro XML, selecione o ícone do lápis.
Vejo a mensagem "Processo de Trabalhador pediu reciclagem devido ao

limite de 'Memória Por Cento'." Como posso abordar esta questão?
A quantidade máxima de memória disponível para um processo de 32 bits (mesmo num sistema operativo de 64
bits) é de 2 GB. Por padrão, o processo do trabalhador está definido para 32 bits no App Service (para
compatibilidade com aplicações web legados).
Considere mudar para processos de 64 bits para que possa tirar partido da memória adicional disponível no seu
papel de Web Worker. Isto despoleta o reinício de uma aplicação web, por isso, agende em conformidade.
Note também que um ambiente de 64 bits requer um plano de serviço Básico ou Standard. Os planos gratuitos e
partilhados funcionam sempre num ambiente de 32 bits.
Para mais informações, consulte as aplicações web da Configure no App Service.
Porque é que o meu pedido acaba depois de 230 segundos?

O Equilíbrio de Carga Azure tem um tempo limite de quatro minutos. Este é geralmente um prazo de resposta
razoável para um pedido web. Se a sua aplicação web necessitar de processamento de fundo, recomendamos a
utilização do Azure WebJobs. A aplicação web Azure pode ligar para webJobs e ser notificada quando o
processamento de fundo estiver terminado. Pode escolher entre vários métodos para usar WebJobs, incluindo filas
e gatilhos.
WebJobs é projetado para processamento de fundo. Pode fazer o processamento de antecedentes que quiser num
WebJob. Para obter mais informações sobre webJobs, consulte executar tarefas de fundo com WebJobs.
ASP.NET aplicações Core que são hospedadas no App Service às vezes

deixam de responder. Como posso resolver este problema?
Um problema conhecido com uma versão kestrel anterior pode fazer com que uma ASP.NET aplicação Core 1.0 que
está hospedada no App Service para parar intermitentemente de responder. Pode também ver esta mensagem: "A
aplicação CGI especificada encontrou um erro e o servidor terminou o processo."
Esta edição é corrigida na versão 1.0.2 da Kestrel. Esta versão está incluída na atualização ASP.NET Core 1.0.3. Para
resolver este problema, certifique-se de atualizar as dependências da sua aplicação para utilizar o Kestrel 1.0.2. Em
alternativa, pode utilizar uma das duas sobras descritas na publicação de blog ASP.NET problemas de perf lentos
Core 1.0 em aplicações web do App Service.
Não encontro os meus ficheiros de registo na estrutura de ficheiros da

minha aplicação web. Como posso encontrá-los?
Se utilizar a funcionalidade Cache Local do Serviço de Aplicações, a estrutura de pastas das pastas LogFiles e Data
para a sua instância de Serviço de Aplicações é afetada. Quando a Cache Local é utilizada, as subpastas são criadas
nas pastas de registo de armazenamento Files e Data. As subpastas utilizam o padrão de nomeação "identificador
único" + carimbo de tempo. Cada subpasta corresponde a uma instância VM em que a aplicação web está a
funcionar ou executa.
Para determinar se está a utilizar cache local, verifique o separador de definições de aplicações do serviço de
aplicações. Se o Cache Local estiver WEBSITE_LOCAL_CACHE_OPTION a ser Always utilizado, a definição da aplicação
está definida para .
Se não estiver a usar cache local e estiver a passar por este problema, apresente um pedido de apoio.
Vejo a mensagem "Foi feita uma tentativa de aceder a uma tomada de

uma forma proibida pelas suas permissões de acesso." Como posso
resolver isto?
Este erro ocorre normalmente se as ligações TCP de saída na instância VM estiverem esgotadas. No Serviço de
Aplicações, são aplicados limites para o número máximo de ligações de saída que podem ser feitas para cada
instância VM. Para mais informações, consulte os limites numéricos cross-VM.
Este erro também pode ocorrer se tentar aceder a um endereço local a partir da sua aplicação. Para mais
informações, consulte os pedidos de morada local.
Para obter mais informações sobre ligações de saída na sua aplicação web, consulte a publicação de blog sobre
ligações de saída a websites Azure.
Como uso o Visual Studio para depurar remotamente a minha aplicação

web do App Service?
Para uma passagem detalhada que lhe mostre como depurar a sua aplicação web usando o Visual Studio, consulte
Remote debug your App Service web app.
FAQs de implementação para Aplicações Web do
Azure
Este artigo tem respostas a perguntas frequentes (PERGUNTAS) sobre questões de implementação para a
funcionalidade de Aplicações Web do Azure App Service.
supor te .
Estou apenas a começar com aplicações web do App Service. Como

publico o meu código?
Aqui estão algumas opções para publicar o seu código de aplicação web:
Implementar utilizando o Estúdio Visual. Se tiver a solução Visual Studio, clique no projeto de aplicação web e,
em seguida, selecione Publicar .
Implementar utilizando um cliente FTP. No portal Azure, faça o download do perfil de publicação para a
aplicação web para a a ação a que pretende implementar o seu código. Em seguida, faça o upload dos ficheiros
para \site\wwwroot utilizando as mesmas credenciais FTP de perfil de publicação.
Para mais informações, consulte A implementação da sua aplicação para o Serviçode Aplicações .
Vejo uma mensagem de erro quando tento ser lançada do Estúdio

Visual. Como resolvo este erro?
Se vir a seguinte mensagem, poderá estar a utilizar uma versão mais antiga do SDK: "Erro durante a
implementação do recurso 'YourResourceName' no grupo de recursos 'YourResourceGroup':
MissingRegistrationForLocation: A subscrição não está registada para os componentes do tipo de recurso no local
'Central US'. Reinscreva-se para este fornecedor de forma a ter acesso a este local."
Para resolver este erro, atualize para o mais recente SDK. Se vir esta mensagem e tiver o mais recente SDK, envie
um pedido de apoio.
Como implemento uma aplicação ASP.NET do Visual Studio para o App

Service?
O tutorial Criar a sua primeira ASP.NET aplicação web em Azure em cinco minutos mostra-lhe como implementar
uma aplicação web ASP.NET para uma aplicação web no App Service utilizando o Visual Studio.
Quais são os diferentes tipos de credenciais de implantação?

O Serviço de Aplicações suporta dois tipos de credenciais para a implantação local de Git e implantação FTP/S. Para
obter mais informações sobre como configurar credenciais de implementação, consulte as credenciais de
implementação do Configure para o Serviçode Aplicações .
Qual é o ficheiro ou estrutura de diretório da minha aplicação web do
App Service?
Para obter informações sobre a estrutura de ficheiros da sua app App Service, consulte a estrutura de ficheiros no
Azure.
Como posso resolver o "Erro FTP 550 - Não há espaço suficiente no

disco" quando tento pôr os meus ficheiros?
Se vir esta mensagem, é provável que esteja a encontrar uma quota de disco no plano de serviço para a sua
aplicação web. Você pode precisar escalar até um nível de serviço mais alto com base nas necessidades do seu
espaço de disco. Para obter mais informações sobre planos de preços e limites de recursos, consulte os preços do
Como configurar a implementação contínua para a minha aplicação

web do App Service?
Pode configurar uma implementação contínua a partir de vários recursos, incluindo Azure DevOps, OneDrive,
GitHub, Bitbucket, Dropbox e outros repositórios Git. Estas opções estão disponíveis no portal. A implementação
contínua para o Serviço de Aplicações é um tutorial útil que explica como configurar a implementação contínua.
Como posso resolver problemas com a implantação contínua do GitHub

e do Bitbucket?
Para ajudar a investigar problemas com a implantação contínua do GitHub ou bitbucket, consulte a investigação
contínua de implantação.
Não posso usar o FTP no meu site e publicar o meu código. Como
posso resolver esta questão?
Para resolver as questões do PFT:
1. Verifique se está a introduzir o nome e credenciais corretas do anfitrião. Para obter informações detalhadas
sobre diferentes tipos de credenciais e como usá-las, consulte as credenciais de implantação.
2. Verifique se as portas FTP não estão bloqueadas por uma firewall. As portas devem ter estas definições:
Porta de ligação de controlo de FTP: 21
Porta de ligação de dados FTP: 989, 10001-10300
Como publico o meu código no Serviço de Aplicações?

O Azure Quickstart foi concebido para o ajudar a implementar a sua aplicação utilizando a pilha de implementação
e o método à sua escolha. Para utilizar o Quickstart, no portal Azure, vá ao seu serviço de aplicações, em
Implementação, selecione Quickstar t .
Porque é que a minha aplicação às vezes reinicia após a implementação

no App Service?
Para conhecer as circunstâncias em que uma implementação de aplicação pode resultar num reinício, consulte
questões de implantação vs. tempode execução . Como o artigo descreve, o Serviço de Aplicações implementa
ficheiros na pasta wwwroot. Nunca reinicia diretamente a sua aplicação.
Como posso integrar o código do Azure DevOps com o Serviço de
Aplicações?
Tem duas opções para utilizar a implantação contínua com o Azure DevOps:
Use um projeto Git. Ligue-se através do Serviço de Aplicações utilizando o Centro de Implantação.
Utilize um projeto team foundation version control (TFVC). Implemente utilizando o agente de construção para
o Serviço de Aplicações.
A implementação contínua de códigos para ambas as opções depende dos fluxos de trabalho existentes para o
desenvolvedor e dos procedimentos de check-in. Para obter mais informações, veja estes artigos:
Implementar a implementação contínua da sua app para um website do Azure
Criar uma organização Azure DevOps para que possa implementar para uma aplicação web
Como uso ftp ou FTPS para implementar a minha aplicação no App

Service?
Para obter informações sobre a utilização de FTP ou FTPS para implementar a sua aplicação web para o App
Service, consulte a implementação da sua aplicação para o Serviço de Aplicações utilizando FTP/S.
Tecnologias de código aberto FAQs para Web Apps
em Azure
Este artigo tem respostas a perguntas frequentes (FAQs) sobre problemas com tecnologias de código aberto para a
supor te .
Como posso ligar o registo de PHP para resolver problemas de PHP?

Para ligar a registo de PHP:
1. Inscreva-se no seu website da Kudu https://*yourwebsitename*.scm.azurewebsites.net ().
2. No menu superior, selecione Debug Console > CMD .
3. Selecione a pasta 'Site'.
4. Selecione a pasta wwwroot.
5. Selecione o + ícone e, em seguida, selecione Novo Ficheiro .
6. Desaveie o nome do ficheiro para .user.ini .
7. Selecione o ícone do lápis ao lado de .user.ini .
8. No ficheiro, adicione este código: log_errors=on
10. Selecione o ícone do lápis ao lado de wp-config.php .
11. Altere o texto para o seguinte código:
//Enable WP_DEBUG modedefine('WP_DEBUG', true);//Enable debug logging to /wp-

content/debug.logdefine('WP_DEBUG_LOG', true);
//Suppress errors and warnings to screendefine('WP_DEBUG_DISPLAY', false);//Suppress PHP errors to
screenini_set('display_errors', 0);
12. No portal Azure, no menu de aplicações web, reinicie a sua aplicação web.
Para obter mais informações, consulte ativar os registos de erro wordpress.
Como faço o registo de erros de aplicação Python em aplicações que

estão hospedadas no Serviço de Aplicações?
Se python encontrar um erro durante o início da sua aplicação, apenas uma simples página de erro será devolvida
(por exemplo, "A página não pode ser exibida porque ocorreu um erro interno do servidor.").
Para capturar erros de aplicação python:
1. No portal Azure, na sua aplicação web, selecione Definições .
2. No separador Definições, selecione definições de aplicação .
3. Nas definições da App, introduza o seguinte par chave/valor:
Chave : WSGI_LOG
Valor : D:\home\site\wwwroot\logs.txt (insira a sua escolha de nome de ficheiro)
Deverá agora ver erros no ficheiro logs.txt na pasta wwwroot.
Como posso alterar a versão da aplicação Node.js que está hospedada

no Serviço de Aplicações?
Para alterar a versão da aplicação Node.js, pode utilizar uma das seguintes opções:
No portal Azure, utilize as definições de App .
2. Na lâmina Definições, selecione definições de aplicação .
3. Nas definições de App, pode incluir WEBSITE_NODE_DEFAULT_VERSION como chave, e a versão de
Node.js que pretende como valor.
4. Vá para a sua consola Kudu https://*yourwebsitename*.scm.azurewebsites.net ().
5. Para verificar a versão Node.js, insira o seguinte comando:
node -v
Modifique o ficheiro iisnode.yml. Alterar a versão Node.js no ficheiro iisnode.yml apenas define o ambiente
de tempo de execução que o iisnode utiliza. O seu Kudu cmd e outros ainda utilizam a versão Node.js que
está definida nas definições de App no portal Azure.
Para definir o iisnode.yml manualmente, crie um ficheiro iisnode.yml na pasta raiz da sua aplicação. No
ficheiro, inclua a seguinte linha:
nodeProcessCommandLine: "D:\Program Files (x86)\nodejs\5.9.1\node.exe"
Desave o ficheiro iisnode.yml utilizando o package.json durante a implantação do controlo de origem. O

processo de implantação do controlo de fontes Azure envolve as seguintes etapas:
1. Move o conteúdo para a aplicação web Azure.
2. Cria um script de implementação predefinido, se não houver um (implementar ficheiros.cmd,
.deployment files) na pasta raiz da aplicação web.
3. Executa um script de implementação no qual cria um ficheiro iisnode.yml se mencionar a versão Node.js
no ficheiro pacote.json > motor "engines": {"node": "5.9.1","npm": "3.7.3"}
4. O ficheiro iisnode.yml tem a seguinte linha de código:
nodeProcessCommandLine: "D:\Program Files (x86)\nodejs\5.9.1\node.exe"
Vejo a mensagem "Erro que estabelece uma ligação de base de dados"

na minha aplicação WordPress que está hospedada no Serviço de
Aplicações. Como é que resolvo isto?
Se vir este erro na sua aplicação Azure WordPress, para ativar php_errors.log e debug.log, preencha os passos
detalhados nos registos de erro do Enable WordPress.
Quando os registos estiverem ativados, reproduza o erro e, em seguida, verifique os registos para ver se está a ficar
sem ligações:
[09-Oct-2015 00:03:13 UTC] PHP Warning: mysqli_real_connect(): (HY000/1226): User ‘abcdefghijk79' has exceeded
the ‘max_user_connections’ resource (current value: 4) in D:\home\site\wwwroot\wp-includes\wp-db.php on line
1454
Se vir este erro nos ficheiros de debug.log ou php_errors.log, a sua aplicação excede o número de ligações. Se
estiver hospedado no ClearDB, verifique o número de ligações disponíveis no seu plano de serviço.
Como depurar uma aplicação Node.js que está hospedada no Serviço

de Aplicações?
1. Vá para a sua consola Kudu https://*yourwebsitename*.scm.azurewebsites.net/DebugConsole ().
2. Aceda à pasta de registos de aplicações (D:\home\LogFiles\Application).
3. No ficheiro logging_errors.txt, verifique se há conteúdo.
Como posso instalar módulos Python nativos numa aplicação web do

Serviço de Aplicações ou numa aplicação API?
Algumas embalagens podem não ser instaladas utilizando pip em Azure. O pacote pode não estar disponível no
Python Package Index, ou pode ser necessário um compilador (um compilador não está disponível no computador
que está a executar a aplicação web no Serviço de Aplicações). Para obter informações sobre a instalação de
módulos nativos em aplicações web do App Service e aplicações API, consulte instalar módulos Python no Serviço
de Aplicações.
Como posso implementar uma aplicação Django para o App Service

usando o Git e a nova versão do Python?
Para obter informações sobre a instalação do Django, consulte implementar uma aplicação Django para o Serviço
de Aplicações.
Onde estão os ficheiros de registo do Tomcat?

Para a Azure Marketplace e implementações personalizadas:
Localização da pasta: D:\home\site\wwwroot\bin\apache-tomcat-8.0.33\logs
Ficheiros de interesse:
A Catalina. yyyy-mm-dd.log
anfitrião-gerente. yyyy-mm-dd.log
local. yyyy-mm-dd.log
gerente. yyyy-mm-dd.log
site_access_log. yyyy-mm-dd.log
Para implementações de configurações de aplicações do portal app:
Localização da pasta: D:\home\LogFiles
Ficheiros de interesse:
A Catalina. yyyy-mm-dd.log
anfitrião-gerente. yyyy-mm-dd.log
local. yyyy-mm-dd.log
gerente. yyyy-mm-dd.log
site_access_log. yyyy-mm-dd.log
Como é que resolvo os erros de ligação do condutor JDBC?
Pode ver a seguinte mensagem nos seus registos Tomcat:
The web application[ROOT] registered the JDBC driver [com.mysql.jdbc.Driver] but failed to unregister it when
the web application was stopped. To prevent a memory leak,the JDBC Driver has been forcibly unregistered
Para resolver o erro:

1. Retire o ficheiro sqljdbc*.jar da sua pasta app/lib.
2. Se estiver a utilizar o servidor web Tomcat ou Azure Marketplace Tomcat, copie este ficheiro .jar para a pasta
Lib Tomcat.
3. Se estiver a ativar a Java a partir do portal Azure (selecione Java 1.8 > Tomcat ser ver), copie o ficheiro de
frasco sqljdbc.* na pasta paralela à sua aplicação. Em seguida, adicione a seguinte definição de classe ao
ficheiro web.config:
<httpPlatform>
<environmentVariables>
<environmentVariablename ="JAVA_OPTS" value=" -Djava.net.preferIPv4Stack=true
-Xms128M -classpath %CLASSPATH%;[Path to the sqljdbc*.jarfile]" />
</environmentVariables>
</httpPlatform>
Por que vejo erros quando tento copiar ficheiros de registos ao vivo?
Se tentar copiar ficheiros de registo ao vivo para uma aplicação Java (por exemplo, Tomcat), poderá ver este erro
FTP:
Error transferring file [filename] Copying files from remote side failed.
The process cannot access the file because it is being used by another process.
A mensagem de erro pode variar, dependendo do cliente FTP.

Todas as aplicações java têm este problema de bloqueio. Apenas a Kudu suporta o download deste ficheiro
enquanto a aplicação está em execução.
Parar a aplicação permite o acesso ftp a estes ficheiros.
Outra solução alternativa é escrever um WebJob que executa um horário e copia estes ficheiros para um diretório
diferente. Para um projeto de amostra, consulte o projeto CopyLogsJob.
Onde encontro os registos do Jetty?

Para o Marketplace e as implementações personalizadas, o ficheiro de registo encontra-se na pasta
D:\home\site\wwwroot\bin\jetty-distribution-9.1.2.v20140210\logs. Note que a localização da pasta depende da
versão do Jetty que está a utilizar. Por exemplo, o caminho aqui fornecido é para Jetty 9.1.2. Procure
jetty_YYYY_MM_DD.stderrout.log.
Para implementações de Definição de aplicativos do portal, o ficheiro de registo está em D:\home\LogFiles. Procure
jetty_YYYY_MM_DD.stderrout.log
Posso enviar e-mail da minha aplicação web Azure?

O Serviço de Aplicações não tem uma funcionalidade de e-mail incorporada. Para algumas boas alternativas para o
envio de e-mail da sua app, consulte esta discussão Stack Overflow.
Porque é que o meu site WordPress redireciona para outro URL?

Se emigrou recentemente para Azure, o WordPress poderá redirecionar para o antigo URL de domínio. Isto é
causado por uma definição na base de dados MySQL.
WordPress Buddy+ é uma extensão do Site Azure que pode utilizar para atualizar o URL de reorientação
diretamente na base de dados. Para obter mais informações sobre a utilização do WordPress Buddy+, consulte as
ferramentas WordPress e a migração MySQL com o WordPress Buddy+.
Em alternativa, se preferir atualizar manualmente o URL de reorientação utilizando consultas SQL ou
PHPMyAdmin, consulte WordPress: Redirecionamento para URL errado.
Como posso alterar a minha palavra-passe de entrada do WordPress?

Se esqueceu a sua palavra-passe de entrada do WordPress, pode utilizar o WordPress Buddy+ para a atualizar. Para
redefinir a sua palavra-passe, instale a extensão do WordPress Buddy+ Azure Site e, em seguida, complete os
passos descritos nas ferramentas WordPress e na migração mySQL com o WordPress Buddy+.
Não posso assinar com o WordPress. Como posso resolver isto?

Se se encontrar bloqueado fora do WordPress depois de ter instalado recentemente um plugin, poderá ter um
plugin defeituoso. WordPress Buddy+ é uma extensão do Site Azure que pode ajudá-lo a desativar plugins no
WordPress. Para mais informações, consulte as ferramentas WordPress e a migração MySQL com o WordPress
Buddy+.
Como posso migrar a minha base de dados WordPress?

Tem várias opções para migrar a base de dados MySQL que está ligada ao seu website WordPress:
Desenvolvedores: Utilize o pedido de comando ou PHPMyAdmin
Não desenvolvedores: Use WordPress Buddy+
Como posso ajudar a tornar o WordPress mais seguro?

Para saber mais sobre as melhores práticas de segurança para o WordPress, consulte as melhores práticas para a
segurança WordPress em Azure.
Estou a tentar usar phpMyAdmin, e vejo a mensagem "Acesso negado".

Como posso resolver isto?
Poderá experimentar este problema se a funcionalidade de aplicação mySQL ainda não estiver em execução neste
caso de Serviço de Aplicações. Para resolver o problema, tente aceder ao seu website. Isto inicia os processos
necessários, incluindo o processo de aplicação MySQL. Para verificar se o MySQL in-app está em execução, no
Process Explorer, certifique-se de que o mysqld.exe está listado nos processos.
Depois de garantir que o MySQL está em execução, tente utilizar PHPMyAdmin.
Recebo um erro HTTP 403 quando tento importar ou exportar a minha

base de dados mySQL in-app utilizando PHPMyadmin. Como posso
resolver isto?
Se estiver a utilizar uma versão mais antiga do Chrome, poderá estar a experimentar um bug conhecido. Para
resolver o problema, atualize para uma versão mais recente do Chrome. Tente também utilizar um navegador
diferente, como o Internet Explorer ou o Microsoft Edge, onde o problema não ocorre.
Configuração e gestão de FAQs para Web Apps em
Azure
Este artigo tem respostas a perguntas frequentes (PERGUNTAS) sobre questões de configuração e gestão para a
supor te .
Há limitações que eu deveria ter em conta se eu quiser mover recursos

do Serviço de Aplicações?
Se planeia transferir recursos do Serviço app para um novo grupo de recursos ou subscrição, existem algumas
limitações a ter em conta. Para mais informações, consulte as limitaçõesdo Serviço de Aplicações .
Como uso um nome de domínio personalizado para a minha aplicação

web?
Para respostas a perguntas comuns sobre o uso de um nome de domínio personalizado com a sua aplicação web
Azure, consulte o nosso vídeo de sete minutos Adicione um nomede domínio personalizado . O vídeo oferece uma
passagem de como adicionar um nome de domínio personalizado. Descreve como usar o seu próprio URL em vez
do URL de *.azurewebsites.net com a sua aplicação web do App Service. Você também pode ver uma passagem
detalhada de como mapear um nomede domínio personalizado .
Como posso comprar um novo domínio personalizado para a minha

aplicação web?
Para aprender a comprar e configurar um domínio personalizado para a sua aplicação web do App Service,
consulte Comprar e configurar um nomede domínio personalizado no Serviço de Aplicações .
Como faço o upload e configurar um certificado TLS/SSL existente para

a minha aplicação web?
Para aprender a carregar e configurar um certificado TLS/SSL personalizado existente, consulte Adicionar um
certificado TLS/SSL à sua aplicação App Service.
Como posso comprar e configurar um novo certificado TLS/SSL em

Azure para a minha aplicação web?
Para aprender a comprar e configurar um certificado TLS/SSL para a sua aplicação web Do Serviço de Aplicações,
consulte Adicionar um certificado TLS/SSL à sua aplicação App Service.
Como posso mover recursos da Application Insights?

Atualmente, a Azure Application Insights não suporta a operação de movimento. Se o seu grupo de recursos
original incluir um recurso Application Insights, não pode mover esse recurso. Se incluir o recurso Application
Insights quando tentar mover uma aplicação do App Service, toda a operação de movimento falha. No entanto, os
Insights de Aplicação e o plano do Serviço de Aplicações não precisam de estar no mesmo grupo de recursos que
a app para a aplicação funcionar corretamente.
Para mais informações, consulte as limitaçõesdo Serviço de Aplicações .
Onde posso encontrar uma lista de orientação e saber mais sobre

operações de mudança de recursos?
As limitações do Serviço de Aplicações mostram-lhe como mover recursos para uma nova subscrição ou para um
novo grupo de recursos na mesma subscrição. Pode obter informações sobre a lista de verificação de movimentos
de recursos, saber quais os serviços que suportam a operação de mudança, e saber mais sobre limitações do
Serviço de Aplicações e outros tópicos.
Como posso definir o fuso horário do servidor para a minha aplicação

web?
Para definir o fuso horário do servidor para a sua aplicação web:
1. No portal Azure, na subscrição do Serviço de Aplicações, vá ao menu de definições de Aplicações.
2. Em termos de definições de Aplicações, adicione esta definição:
Chave = WEBSITE_TIME_ZONE
Valor = O fuso horário que deseja
Para os serviços da App que funcionam no Windows, consulte a coluna Timezone no artigo Predefinido time
zones para valores aceites. Para os serviços da App que funcionam no Linux, detete o nome da base de dados TZ
como o valor do fuso horário. Aqui está um exemplo do nome da base de dados TZ: America/Adak.
Porque é que os meus WebJobs contínuos às vezes falham?

Por padrão, as aplicações web são descarregadas se ficarem inativas por um determinado período de tempo. Isto
permite que o sistema conserve recursos. Nos planos Basic e Standard, pode ligar a definição Always On para
manter a aplicação web carregada a toda a hora. Se a sua aplicação web executar WebJobs contínuos, deve ligar
Sempre Ligado , ou os WebJobs podem não funcionar de forma fiável. Para mais informações, consulte Criar um
WebJob em execução contínua.
Como consigo o endereço IP de saída para a minha aplicação web?

Para obter a lista de endereços IP de saída para a sua aplicação web:
1. No portal Azure, na sua lâmina de aplicação web, vá ao menu Propriedades.
2. Procure endereços ip de saída .
A lista de endereços IP de saída aparece.
Para saber como obter o endereço IP de saída se o seu website estiver hospedado num Ambiente de Serviço de
Aplicações, consulte os endereços da rede Outbound.
Como posso obter um endereço IP reservado ou dedicado para a

minha aplicação web?
Para configurar um endereço IP dedicado ou reservado para chamadas de entrada feitas no seu website da
aplicação Azure, instale e configure um certificado TLS/SSL baseado em IP.
Note que para utilizar um endereço IP dedicado ou reservado para chamadas de entrada, o seu plano de Serviço
de Aplicações deve estar num plano de serviço básico ou superior.
Posso exportar o meu certificado de Serviço de Aplicações para usar

fora do Azure, como para um site hospedado noutro lugar?
Sim, pode exportá-los para usar fora de Azure. Para mais informações, consulte faQs para certificados de serviço
de aplicações e domínios personalizados.
Posso exportar o meu certificado de Serviço de Aplicações para usar

com outros serviços de nuvem Azure?
O portal fornece uma experiência de primeira classe para a implementação de um certificado de Serviço de
Aplicações através do Azure Key Vault para aplicações do App Service. No entanto, temos recebido pedidos de
clientes para usar estes certificados fora da plataforma do Serviço de Aplicações, por exemplo, com máquinas
virtuais Azure. Para aprender a criar uma cópia PFX local do seu certificado de Serviço de Aplicações para que
possa utilizar o certificado com outros recursos Do Azure, consulte Criar uma cópia PFX local de um certificado de
Para mais informações, consulte faQs para certificados de serviço de aplicações e domínios personalizados.
Por que vejo a mensagem "Parcialmente bem sucedida" quando tento

fazer o back up da minha aplicação web?
Uma causa comum de falha de cópia de segurança é que alguns ficheiros estão a ser utilizados pela aplicação. Os
ficheiros que estão a ser utilizados estão bloqueados enquanto executa a cópia de segurança. Isto impede que
estes ficheiros sejam apoiados e possam resultar num estado "Parcialmente bem sucedido". Pode potencialmente
impedir que isso ocorra excluindo ficheiros do processo de cópia de segurança. Pode supor apenas o que é
necessário. Para mais informações, consulte a cópia de segurança apenas as partes importantes do seu site com
aplicações web Azure.
Como retiro um cabeçalho da resposta HTTP?

Para remover os cabeçalhos da resposta HTTP, atualize o ficheiro web.config do seu site. Para mais informações,
consulte Remova os cabeçalhos padrão do servidor nos seus websites Do Azure.
O Serviço de Aplicações está em conformidade com o PCI Standard 3.0

e 3.1?
Atualmente, a funcionalidade de Aplicações Web do Serviço de Aplicações Azure está em conformidade com a
versão 3.0 Nível 1 da PcI Data Security Standard (DSS). A versão 3.1 do PCI DSS está no nosso roteiro. Já está em
curso o planeamento para a forma como a adoção da última norma irá prosseguir.
A certificação 3.1 da versão PCI DSS requer desativar a Segurança da Camada de Transporte (TLS) 1.0. Atualmente,
desativar o TLS 1.0 não é uma opção para a maioria dos planos do Serviço de Aplicações. No entanto, se utilizar o
App Service Environment ou estiver disposto a migrar a sua carga de trabalho para o App Service Environment,
poderá obter um maior controlo do seu ambiente. Isto envolve desativar o TLS 1.0 contactando o Suporte Azure.
Num futuro próximo, pretendemos tornar estas definições acessíveis aos utilizadores.
Para mais informações, consulte o microsoft Azure App Service na web compliance com PCI Standard 3.0 e 3.1.
Como uso o ambiente de encenação e as ranhuras de implantação?
Nos planos standard e premium do App Service, quando implementar a sua aplicação web para o App Service,
pode ser implementado para uma ranhura de implementação separada em vez da ranhura de produção padrão.
As ranhuras de implementação são aplicações web ao vivo que têm os seus próprios nomes de anfitriões. Os
elementos de conteúdo e configuração da aplicação web podem ser trocados entre duas ranhuras de
implementação, incluindo a ranhura de produção.
Para obter mais informações sobre a utilização de ranhuras de implementação, consulte Configurar um ambiente
de encenação no Serviçode Aplicações .
Como posso aceder e rever os registos do WebJob?

Para rever os registos do WebJob:
2. Selecione o WebJob.
3. Selecione o botão Toggle Output.
4. Para descarregar o ficheiro de saída, selecione o link Download.
5. Para execuções individuais, selecione Individual Invoke .
6. Selecione o botão Toggle Output.
7. Selecione o link de descarregamento.
Estou a tentar usar ligações híbridas com o Servidor SQL. Por que vejo
a mensagem "System.OverflowException: A operação aritmética
resultou num transbordo"?
Se utilizar ligações híbridas para aceder ao SQL Server, uma atualização Microsoft .NET no dia 10 de maio de 2016,
pode causar falhas nas ligações. Pode ver esta mensagem:
Exception: System.Data.Entity.Core.EntityException: The underlying provider failed on Open. —>

System.OverflowException: Arithmetic operation resulted in an overflow. or (64 bit Web app)
System.OverflowException: Array dimensions exceeded supported range, at
System.Data.SqlClient.TdsParser.ConsumePreLoginHandshake
Resolução
A exceção foi causada por um problema com o Gestor de Ligação Híbrido que entretanto foi corrigido. Certifique-
se de atualizar o seu Gestor de Ligação Híbrida para resolver este problema.
Como adiciono uma regra de reescrita de URL?

Para adicionar uma regra de reescrita de URL, crie um ficheiro web.config com as entradas config relevantes na
pasta wwwroot. Para mais informações, consulte Azure App Services: Understanding URL rewrite.
Como controlo o tráfego de entrada para o Serviço de Aplicações?

Ao nível do site, tem duas opções para controlar o tráfego de entrada para o App Service:
Ligue as restrições dinâmicas de IP. Para aprender a ativar restrições ip dinâmicas, consulte restrições IP e
domínio para websites Azure.
Ligue a Segurança do Módulo. Para saber como ativar a Segurança do Módulo, consulte a firewall de aplicação
web modSecurity nos websites do Azure.
Se utilizar o App Service Environment, pode utilizar a firewall Barracuda.
Como posso bloquear portas numa aplicação web do App Service?

No app service compartilhado ambiente de inquilinos, não é possível bloquear portos específicos devido à
natureza da infraestrutura. As portas TCP 4020, 4022 e 4024 também podem estar abertas para depuração remota
do Estúdio Visual.
No App Service Environment, tem total controlo sobre o tráfego de entrada e saída. Pode utilizar grupos de
segurança de rede para restringir ou bloquear portas específicas. Para obter mais informações sobre o Ambiente
do Serviço de Aplicações, consulte a introdução do Ambiente do Serviço de Aplicações.
Como posso capturar um vestígio de F12?

Tem duas opções para capturar um vestígio de F12:
Traço f12 HTTP
Saída da consola F12
Traço f12 HTTP
1. No Internet Explorer, vá ao seu site. É importante assinar antes de fazer os próximos passos. Caso contrário, o
vestígio De F12 captura dados sensíveis de inscrição.
2. Prima F12.
3. Verifique se o separador Rede está selecionado e, em seguida, selecione o botão reproduzir verde.
4. Faça os passos que reproduzem a questão.
5. Selecione o botão stop vermelho.
6. Selecione o botão Guardar (ícone do disco) e guarde o ficheiro HAR (no Internet Explorer e Microsoft Edge) ou
clique na direita no ficheiro HAR e, em seguida, selecione Guardar como HAR com conteúdo (no Chrome).
Saída da consola F12
1. Selecione o separador Consola.
2. Para cada separador que contenha mais de zero itens, selecione o separador (Error, Warning , or
Information ). Se o separador não for selecionado, o ícone do separador é cinzento ou preto quando se afasta
do cursor.
3. Clique à direita na área da mensagem do painel e, em seguida, selecione Copiar tudo .
4. Colhe o texto copiado num ficheiro e, em seguida, guarde o ficheiro.
Para ver um ficheiro HAR, pode utilizar o espectador HAR.
Porque é que tenho um erro quando tento ligar uma aplicação web do
App Service a uma rede virtual que está ligada ao ExpressRoute?
Se tentar ligar uma aplicação web Azure a uma rede virtual ligada ao Azure ExpressRoute, falha. A seguinte
mensagem aparece: "Gateway não é um gateway VPN."
Atualmente, não pode ter ligações VPN ponto-a-site a uma rede virtual que está ligada ao ExpressRoute. Uma VPN
e ExpressRoute ponto-a-site não podem coexistir para a mesma rede virtual. Para mais informações, consulte os
limites e limitações das ligações VPN expressRoute e do site-to-site.
Como posso ligar uma aplicação web do App Service a uma rede virtual
que tem um gateway de encaminhamento estático (baseado em
políticas) ?
Atualmente, a ligação de uma aplicação web do App Service a uma rede virtual que tenha um gateway de
encaminhamento estático (baseado em políticas) não é suportada. Se a sua rede virtual alvo já existir, deve ter VPN
de ponto a site ativado, com um gateway de encaminhamento dinâmico, antes de poder ser ligado a uma
aplicação. Se o seu portal estiver definido para o encaminhamento estático, não pode ativar uma VPN ponto-a-
local.
Para mais informações, consulte Integrar uma aplicação com uma rede virtual Azure.
No meu App Service Environment, por que posso criar apenas um

plano de Serviço de Aplicações, mesmo tendo dois trabalhadores
disponíveis?
Para fornecer tolerância a falhas, o App Service Environment requer que cada grupo de trabalhadores precise de
pelo menos um recurso de computação adicional. O recurso de cálculo adicional não pode ser atribuído a uma
carga de trabalho.
Para mais informações, consulte Como criar um Ambiente de Serviço de Aplicações.
Por que vejo intervalos quando tento criar um Ambiente de Serviço de

Aplicações?
Às vezes, a criação de um App Service Environment falha. Nesse caso, vê-se o seguinte erro nos registos de
Atividade:
ResourceID: /subscriptions/{SubscriptionID}/resourceGroups/Default-
Networking/providers/Microsoft.Web/hostingEnvironments/{ASEname}
Error:{"error":{"code":"ResourceDeploymentFailure","message":"The resource provision operation did not
complete within the allowed timeout period."}}
Para resolver isto, certifique-se de que nenhuma das seguintes condições é verdadeira:
A sub-rede é muito pequena.
A sub-rede não está vazia.
O ExpressRoute impede os requisitos de conectividade da rede de um Ambiente de Serviço de Aplicações.
Um mau Grupo de Segurança da Rede impede os requisitos de conectividade da rede de um Ambiente de
O túnel forçado está ligado.
Para mais informações, consulte questões frequentes ao implementar (criando) um novo Ambientede Serviço de
Aplicações Azure .
Por que não posso apagar o meu plano de Serviço de Aplicações?

Não é possível eliminar um plano de Serviço de Aplicações se alguma aplicação do Serviço de Aplicações estiver
associada ao plano do Serviço de Aplicações. Antes de eliminar um plano de Serviço de Aplicações, remova todas
as aplicações associadas do App Service do plano de Serviço de Aplicações.
Como posso agendar um WebJob?

Você pode criar um WebJob agendado usando expressões Cron:
1. Crie um ficheiro de definições.job.
2. Neste ficheiro JSON, inclua uma propriedade de horário usando uma expressão Cron:
{ "schedule": "{second}
{minute} {hour} {day}
{month} {day of the week}" }
Para obter mais informações sobre webJobs agendados, consulte Criar um WebJob agendado utilizando uma
expressão Cron.
Como faço testes de penetração para a minha aplicação App Service?

Para efetuar testes de penetração, submeta um pedido.
Como configurar um nome de domínio personalizado para uma

aplicação web do App Service que utiliza o Traffic Manager?
Para aprender a usar um nome de domínio personalizado com uma aplicação de Serviço de Aplicações que utiliza
o Gestor de Tráfego Azure para equilibrar a carga, consulte configurar um nome de domínio personalizado para
uma aplicação web Azure com traffic Manager.
O meu certificado do Serviço de Aplicações está sinalizado por fraude.

Como posso resolver isto?
NOTE
Durante a verificação do domínio de uma compra de certificado de serviço de aplicações, pode ver a seguinte
mensagem:
"O seu certificado foi sinalizado por possível fraude. O pedido está atualmente a ser analisado. Se o certificado não
for utilizável dentro de 24 horas, contacte o Suporte Azure."
Como a mensagem indica, este processo de verificação de fraude pode demorar até 24 horas para ser concluído.
Durante este tempo, continuará a ver a mensagem.
Se o seu certificado de Serviço de Aplicações continuar a mostrar esta mensagem após 24 horas, por favor,
execute o seguinte script PowerShell. O script contacta o fornecedor de certificados diretamente para resolver o
problema.
Connect-AzAccount
Set-AzContext -SubscriptionId <subId>
$actionProperties = @{
"Name"= "<Customer Email Address>"
};
Invoke-AzResourceAction -ResourceGroupName "<App Service Certificate Resource Group Name>" -ResourceType
Microsoft.CertificateRegistration/certificateOrders -ResourceName "<App Service Certificate Resource Name>" -
Action resendRequestEmails -Parameters $actionProperties -ApiVersion 2015-08-01 -Force
Como funciona a autenticação e autorização no Serviço de Aplicações?

Para obter documentação detalhada para autenticação e autorização no Serviço de Aplicações, consulte os
documentos para vários registos de prestadores de identificação:
Azure Active Directory
Facebook
Google
Conta Microsoft
Twitter
Como redireciono o domínio padrão *.azurewebsites.net para o

domínio personalizado da minha aplicação web Azure?
Quando cria um novo website utilizando aplicações web em Azure, um site padrãode nome de azurewebsites.net é
atribuído ao seu site. Se adicionar um nome de anfitrião personalizado ao seu site e não quiser que os utilizadores
possam aceder ao seu domínio padrão *.azurewebsites.net, pode redirecionar o URL predefinido. Para aprender a
redirecionar todo o tráfego do domínio padrão do seu website para o seu domínio personalizado, consulte
Redirecionar o domínio padrão para o seu domínio personalizado em aplicações web Azure.
Como determino qual versão da versão .NET está instalada no Serviço

de Aplicações?
A forma mais rápida de encontrar a versão da Microsoft .NET que está instalada no App Service é utilizando a
consola Kudu. Pode aceder à consola Kudu a partir do portal ou utilizando o URL da sua aplicação App Service.
Para obter instruções detalhadas, consulte determinar a versão .NET instalada no Serviço de Aplicações.
Porque é que a Escala Automática não está a funcionar como

esperado?
Se a Azure Autoscale não tiver escalado ou dimensionado a instância da aplicação web como esperava, poderá
estar a deparar-se com um cenário em que intencionalmente optamos por não escalar para evitar um loop infinito
devido a "bater palmas". Isto geralmente acontece quando não há uma margem adequada entre os limiares de
escala e escala.dentro. Para aprender a evitar "bater palmas" e ler sobre outras boas práticas de escala automática,
consulte as melhores práticas da Autoscale.
Por que a Escala Automática às vezes escala apenas parcialmente?

A escala automática é ativada quando as métricas excedem os limites pré-configurados. Às vezes, nota-se que a
capacidade só está parcialmente preenchida em comparação com o que se esperava. Isto pode ocorrer quando o
número de casos que deseja não estiver disponível. Nesse cenário, a Escala Automática preenche parcialmente o
número de casos disponíveis. A escala automática executa então a lógica de reequilíbrio para obter mais
capacidade. Atribui as restantes instâncias. Note que isto pode demorar alguns minutos.
Se não vir o número esperado de casos após alguns minutos, pode ser porque a recarga parcial foi suficiente para
colocar as métricas dentro dos limites. Ou, a escala automática pode ter diminuído porque atingiu o limite das
métricas mais baixas.
Se nenhuma destas condições se aplicar e o problema persistir, apresente um pedido de apoio.
Como ligo a compressão HTTP para o meu conteúdo?

Para ligar a compressão tanto para tipos de conteúdo estático como dinâmico, adicione o seguinte código ao
ficheiro web.config de nível de aplicação:
<system.webServer>
<urlCompression doStaticCompression="true" doDynamicCompression="true" />
</system.webServer>
Também pode especificar os tipos específicos de MIME dinâmicos e estáticos que pretende comprimir. Para mais
informações, consulte a nossa resposta a uma questão do fórum em definições de httpCompression num simples
website Azure.
Como migrado de um ambiente no local para o Serviço de Aplicações?

Para migrar sites de servidores web Windows e Linux para o App Service, pode utilizar o Assistente de Migração
do Serviço de Aplicações Azure. A ferramenta de migração cria aplicações web e bases de dados em Azure
conforme necessário, e depois publica o conteúdo. Para mais informações, consulte O Assistente de Migração do
Como preparar uma alteração de endereço IP de
entrada
Se recebeu uma notificação de que o endereço IP de entrada da sua aplicação Azure App Service está a mudar, siga
as instruções deste artigo.
Determine se tem que fazer alguma coisa.

Opção 1: Se a sua aplicação de Serviço de Aplicações não tiver um Domínio Personalizado, não é necessária
qualquer ação.
Opção 2: Se apenas um registo CNAME (registo DNS apontando para um URI) estiver configurado no seu
Portal de Registo de Domínio (Fornecedor DNS de terceiros ou DNS Azure), não é necessária qualquer ação.
Opção 3: Se um registo (registo DNS apontado diretamente para o seu endereço IP) estiver configurado no
seu Portal de Registo de Domínio (Fornecedor DNS de terceiros ou DNS Azure), substitua o endereço IP
existente pelo novo. Pode encontrar o novo endereço IP seguindo as instruções na secção seguinte.
Opção 4: Se a sua aplicação estiver por trás de um balanceador de carga, filtro IP ou qualquer outro
mecanismo IP que exija o endereço IP da sua aplicação, substitua o endereço IP existente pelo novo. Pode
encontrar o novo endereço IP seguindo as instruções na secção seguinte.
Encontre o novo endereço IP de entrada no portal Azure

O novo endereço IP de entrada que está a ser dado à sua aplicação está no portal no campo de endereços IP
vir tual. Tanto este novo endereço IP como o antigo estão agora ligados à sua aplicação, e mais tarde o antigo será
desligado.
2. No menu de navegação à esquerda, selecione Serviços de Aplicações .
3. Selecione a sua aplicação App Service da lista.
4. Se a aplicação for uma aplicação de função, consulte o endereço IP de entrada da aplicação Função.
5. No cabeçalho Definições, clique em Propriedades na navegação à esquerda e encontre o endereço IP
vir tual da secção rotulado .
6. Copie o endereço IP e reconfigure o seu registo de domínio ou mecanismo IP.
Passos seguintes
Este artigo explicou como se preparar para uma mudança de endereço IP que foi iniciada pelo Azure. Para obter
mais informações sobre endereços IP no Serviço de Aplicações Azure, consulte endereços IP de entrada e saída no
Como preparar-se para uma mudança de endereço
IP de saída
Se recebeu uma notificação de que os endereços IP de saída da sua aplicação Azure App Service estão a mudar,
siga as instruções deste artigo.
Determine se tem que fazer alguma coisa.

Opção 1: Se a sua aplicação app Service não utilizar a filtragem IP, uma lista de inclusão explícita ou um
manuseamento especial do tráfego de saída, como encaminhamento ou firewall, não é necessária qualquer
ação.
Opção 2: Se a sua aplicação tiver um manuseamento especial para os endereços IP de saída (ver exemplos
abaixo), adicione os novos endereços IP de saída onde quer que os existentes apareçam. Não substitua os
endereços IP existentes. Pode encontrar os novos endereços IP de saída seguindo as instruções na secção
seguinte.
Por exemplo, um endereço IP de saída pode ser explicitamente incluído numa firewall fora da sua aplicação,
ou um serviço de pagamento externo pode ter uma lista permitida que contenha o endereço IP de saída
para a sua aplicação. Se o seu endereço de saída estiver configurado numa lista fora da sua aplicação, isso
tem de ser alterado.
Encontre os endereços IP de saída no portal Azure

Os novos endereços IP de saída são mostrados no portal antes de produzirem efeito. Quando o Azure começar a
usar os novos, os antigos deixarão de ser utilizados. Apenas um conjunto de cada vez é utilizado, pelo que as
inscrições nas listas de inclusão devem ter endereços IP antigos e novos para evitar uma interrupção quando o
interruptor acontece.
4. Se a aplicação for uma aplicação de função, consulte os endereços IP de saídada aplicação Function .
5. No cabeçalho Definições, clique em Propriedades na navegação à esquerda e encontre a secção
etiquetada endereços IP outbound .
6. Copie os endereços IP e adicione-os ao seu manuseamento especial de tráfego de saída, como um filtro ou
lista permitida. Não elimine os endereços IP existentes na lista.
Passos seguintes
Como preparar uma alteração de endereço IP SSL
Se recebeu uma notificação de que o endereço IP SSL da sua aplicação Azure App Service está a mudar, siga as
instruções deste artigo para lançar o endereço IP sSL existente e atribua um novo.
Lançar endereços IP SSL e atribuir novos

4. No cabeçalho Definições, clique nas definições SSL na navegação à esquerda.
5. Na secção de encadernações TLS/SSL, selecione o registo de nome do anfitrião. No editor que abre, escolha
SNI SSL no menu de entrega do Tipo SSL e clique em Adicionar Encadernação . Quando vê a
mensagem de sucesso da operação, o endereço IP existente foi lançado.
6. Na secção de encadernações SSL, selecione novamente o mesmo registo de nome do anfitrião com o
certificado. No editor que abre, desta vez escolha o Ip Based SSL no menu de entrega do Tipo SSL e
clique em Adicionar Encadernação . Quando vê a mensagem de sucesso da operação, adquiriu um novo
endereço IP.
7. Se um registo A (registo DNS apontado diretamente para o seu endereço IP) estiver configurado no seu
Portal de Registo de Domínio (Fornecedor DNS de terceiros ou DNS Azure), substitua o endereço IP
existente pelo recém-gerado. Pode encontrar o novo endereço IP seguindo as instruções na secção seguinte.
Encontre o novo endereço IP SSL no Portal Azure

1. Espere alguns minutos e abra o portal Azure.
4. No cabeçalho Definições, clique em Propriedades na navegação à esquerda e encontre o endereço IP
vir tual da secção rotulado .
5. Copie o endereço IP e reconfigure o seu registo de domínio ou mecanismo IP.
Passos seguintes

Azure - Serviçoes de Aplicações

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Azure - Serviçoes de Aplicações

Enviado por

Direitos autorais:

Formatos disponíveis

Contents

Documentação do Serviço de Aplicações

Porquê utilizar o App Service?

Consola, Publicação e Depuração

Suporte de rede virtual

Ambiente do Serviço de Aplicações v1

Criar uma aplicação Web ASP.NET Core

DEF IN IÇ Ã O VA LO R SUGERIDO DESC RIÇ Ã O

Plano de Hospedagem myFirstAzureWebAppPlan Nome do plano de serviço de

Localização Europa ocidental O centro de dados onde o a

Tamanho Gratuito O escalão de preço determina as

10. Assim que o assistente estiver concluído, selecione Publicar .

Atualizar a aplicação e reimplementar

Gerir a app Azure

Na página de Serviços de Aplicações, selecione o nome da sua aplicação web.

Criar uma aplicação web ASP.NET

DEF IN IÇ Ã O VA LO R SUGERIDO DESC RIÇ Ã O

Plano de Alojamento myAppServicePlan Nome do plano de serviço de

Localização Europa ocidental O centro de dados onde o a

Tamanho Gratuito O escalão de preço determina as

9. Selecione Criar para começar a criar os recursos do Azure.

Atualizar a aplicação e reimplementar

Gerir a app Azure

Clone e executar uma aplicação local de Node.js

git clone https://github.com/Azure-Samples/nodejs-docs-hello-world

2. Navegue na nova pasta de aplicações:

3. Inicie a aplicação para testá-la localmente:

Implementar a aplicação no Azure

4. Escolha a pasta nodejs-docs-hello-world.

b. Introduza WEBSITE_NODE_DEFAULT_VERSION para a tecla de definição.

Connecting to log stream...

Dei conta de um problema.

Transferir o exemplo localmente

git clone https://github.com/Azure-Samples/php-docs-hello-world

Executar a aplicação localmente

Na janela do terminal, prima Ctrl+C para sair do servidor Web.

Utilizar o Azure Cloud Shell

OPÇ ÃO EXEM P LO / L IGA Ç Ã O

Selecione Experimentar no canto superior direito de um

Aceda a https://shell.azure.com ou selecione o botão Iniciar

Selecione o botão Cloud Shell na barra de menus, na parte

Para executar o código neste artigo no Azure Cloud Shell:

Configurar um utilizador de implementação

az webapp deployment user set --user-name <username> --password <password>

Criar um grupo de recursos

az group create --name myResourceGroup --location "West Europe"

Criar um plano do Serviço de Aplicações do Azure

az appservice plan create --name myAppServicePlan --resource-group myResourceGroup --sku FREE

Criar uma aplicação Web

Local git is configured with url of 'https://<username>@<app-name>.scm.azurewebsites.net/<app-

Criou uma nova aplicação vazia, com a implementação de git habilitada.

A aplicação Web deve ter o seguinte aspeto:

Enviar para o Azure a partir do Git

git remote add azure <deploymentLocalGitUrl-from-create-step>

git push azure master

Navegar para a aplicação

Parabéns! Implementou a sua primeira aplicação PHP no Serviço de Aplicações.

Atualizar localmente e reimplementar o código

echo "Hello Azure!";

git commit -am "updated output"

Gerencie a sua nova app Azure

2. Selecione o nome da sua aplicação Azure.

az group delete --name myResourceGroup

Este comando pode demorar alguns minutos a ser executado.