Pular para o conteúdo principal

Desafio 10: Azure App Service

Informação

Tempo estimado: 60–75 minutos | Custo estimado: ~$0.20 (tier S1, exclua rapidamente) | Peso no exame: 20–25%

Cenário​

A equipe de marketing da Contoso precisa de uma aplicação web implantada para uma campanha futura. O site deve suportar implantações sem tempo de inatividade, auto-scaling durante picos de tráfego e backups regulares. Você vai implantá-lo no Azure App Service com boas práticas de produção | deployment slots, autoscale e controles de rede.

Habilidades do exame cobertas​

HabilidadePeso
Provisionar um plano do App ServiceAlto
Configurar escalabilidade para o App ServiceAlto
Criar um web app no App ServiceAlto
Configurar deployment slotsAlto
Configurar TLS/SSL e certificadosMédio
Mapear domínio DNS personalizado existenteMédio
Configurar backup para o App ServiceMédio
Configurar definições de redeMédio

Referência sysadmin ↔ Azure​

TradicionalEquivalente no Azure
IIS / Apache / Nginx em uma VMAzure App Service
Load balancer + múltiplos servidores IISScale-out do App Service
Registro DNS CNAMEMapeamento de domínio personalizado
web.config / .htaccessConfiguração do App Service (App Settings, Connection Strings)
Implantação blue-greenDeployment slots + swap
Snapshots de VM / scripts de backup via cronApp Service Backup
Regras de firewall no servidor webApp Service Access Restrictions

Tarefas​

Tarefa 1: criar um plano do App Service​

# Criar um grupo de recursos
az group create --name rg-appservice-lab --location eastus

# Criar um plano do App Service (Standard s1: necessário para deployment slots)
az appservice plan create \
--resource-group rg-appservice-lab \
--name plan-contoso-web \
--sku S1 \
--is-linux

# Verificar o plano
az appservice plan show -g rg-appservice-lab -n plan-contoso-web \
--query "{Name:name, SKU:sku.name, Tier:sku.tier, Workers:sku.capacity}" -o table

Tarefa 2: criar um web App​

# Criar um web app com runtime node.js
az webapp create \
--resource-group rg-appservice-lab \
--plan plan-contoso-web \
--name contoso-web-$RANDOM \
--runtime "NODE:18-lts"

# Armazenar o nome do app para uso posterior
APP_NAME=$(az webapp list -g rg-appservice-lab --query "[0].name" -o tsv)
echo "App Name: $APP_NAME"

# Verificar se está em execução
az webapp show -g rg-appservice-lab -n $APP_NAME \
--query "{Name:name, State:state, URL:defaultHostName}" -o table

Tarefa 3: implantar código de exemplo​

# Criar uma aplicação node.js simples
mkdir webapp && cd webapp

cat > index.js << 'EOF'
const http = require('http');
const port = process.env.PORT || 8080;
const version = process.env.APP_VERSION || 'v1';

const server = http.createServer((req, res) => {
res.writeHead(200, { 'Content-Type': 'text/html' });
res.end(`<h1>Contoso Marketing - ${version}</h1><p>Server time: ${new Date()}</p>`);
});

server.listen(port, () => console.log(`Running on port ${port}`));
EOF

cat > package.json << 'EOF'
{
"name": "contoso-web",
"version": "1.0.0",
"scripts": { "start": "node index.js" },
"engines": { "node": ">=18.0.0" }
}
EOF

# Implantar usando zip deploy
zip -r app.zip index.js package.json
az webapp deploy \
--resource-group rg-appservice-lab \
--name $APP_NAME \
--src-path app.zip \
--type zip

# Definir uma configuração de aplicação
az webapp config appsettings set \
--resource-group rg-appservice-lab \
--name $APP_NAME \
--settings APP_VERSION=v1

# Testar a implantação
echo "Visite: https://$APP_NAME.azurewebsites.net"

Tarefa 4: criar um deployment slot de staging​

# Criar um slot de staging
az webapp deployment slot create \
--resource-group rg-appservice-lab \
--name $APP_NAME \
--slot staging

# Verificar o slot
az webapp deployment slot list -g rg-appservice-lab -n $APP_NAME -o table

# O slot de staging tem sua própria URL
echo "URL de Staging: https://$APP_NAME-staging.azurewebsites.net"

Tarefa 5: implantar uma nova versão no staging​

# Atualizar a versão no staging
az webapp config appsettings set \
--resource-group rg-appservice-lab \
--name $APP_NAME \
--slot staging \
--settings APP_VERSION=v2

# Implantar código atualizado no staging
cd webapp
sed -i "s/Contoso Marketing/Contoso Marketing 2.0/" index.js
zip -r app-v2.zip index.js package.json

az webapp deploy \
--resource-group rg-appservice-lab \
--name $APP_NAME \
--slot staging \
--src-path app-v2.zip \
--type zip

# Testar o slot de staging
echo "Staging: https://$APP_NAME-staging.azurewebsites.net"
echo "Produção: https://$APP_NAME.azurewebsites.net"

Tarefa 6: trocar staging e produção​

# Visualizar o que vai mudar
az webapp deployment slot list -g rg-appservice-lab -n $APP_NAME -o table

# Trocar staging para produção (sem tempo de inatividade)
az webapp deployment slot swap \
--resource-group rg-appservice-lab \
--name $APP_NAME \
--slot staging \
--target-slot production

# Verificar: produção agora executa v2, staging tem v1
echo "Produção: https://$APP_NAME.azurewebsites.net"
echo "Staging: https://$APP_NAME-staging.azurewebsites.net"

Tarefa 7: configurar autoscale​

# Obter o ID do recurso do plano do App Service
PLAN_ID=$(az appservice plan show -g rg-appservice-lab -n plan-contoso-web --query id -o tsv)

# Criar configurações de autoscale
az monitor autoscale create \
--resource-group rg-appservice-lab \
--resource plan-contoso-web \
--resource-type Microsoft.Web/serverfarms \
--name autoscale-web \
--min-count 1 \
--max-count 5 \
--count 1

# Escalar quando CPU > 70%
az monitor autoscale rule create \
--resource-group rg-appservice-lab \
--autoscale-name autoscale-web \
--condition "CpuPercentage > 70 avg 5m" \
--scale out 1

# Reduzir quando CPU < 30%
az monitor autoscale rule create \
--resource-group rg-appservice-lab \
--autoscale-name autoscale-web \
--condition "CpuPercentage < 30 avg 10m" \
--scale in 1

# Verificar configurações de autoscale
az monitor autoscale show -g rg-appservice-lab -n autoscale-web \
--query "profiles[0].rules[].{Metric:metricTrigger.metricName, Op:metricTrigger.operator, Threshold:metricTrigger.threshold, Direction:scaleAction.direction}" -o table

Tarefa 8: configurar Backup​

# Criar uma conta de armazenamento para backups
BACKUP_STORAGE="contosobackup$RANDOM"
az storage account create \
--resource-group rg-appservice-lab \
--name $BACKUP_STORAGE \
--sku Standard_LRS

# Criar um contêiner para backups
az storage container create \
--name webapp-backups \
--account-name $BACKUP_STORAGE

# Gerar uma URL SAS para o contêiner
EXPIRY=$(date -u -d "1 year" '+%Y-%m-%dT%H:%MZ')
SAS_URL=$(az storage container generate-sas \
--account-name $BACKUP_STORAGE \
--name webapp-backups \
--permissions rwdl \
--expiry $EXPIRY \
--output tsv)

CONTAINER_URL="https://$BACKUP_STORAGE.blob.core.windows.net/webapp-backups?$SAS_URL"

# Configurar backup
az webapp config backup update \
--resource-group rg-appservice-lab \
--webapp-name $APP_NAME \
--container-url "$CONTAINER_URL" \
--backup-name "contoso-backup" \
--frequency 1d \
--retain-one true

Tarefa 9: configurar restrições de acesso​

# Adicionar uma restrição de acesso baseada em IP (permitir apenas seu ip)
MY_IP=$(curl -s ifconfig.me)

az webapp config access-restriction add \
--resource-group rg-appservice-lab \
--name $APP_NAME \
--rule-name "AllowMyIP" \
--priority 100 \
--ip-address "$MY_IP/32" \
--action Allow

# Adicionar uma regra de negar tudo com prioridade menor
az webapp config access-restriction add \
--resource-group rg-appservice-lab \
--name $APP_NAME \
--rule-name "DenyAll" \
--priority 200 \
--ip-address "0.0.0.0/0" \
--action Deny

# Mostrar regras efetivas
az webapp config access-restriction show \
-g rg-appservice-lab -n $APP_NAME -o table

Critérios de sucesso​

  • ⬜Plano do App Service (Standard S1) criado
  • ⬜Web app implantado e acessível via HTTPS
  • ⬜Deployment slot de staging criado e recebe a v2
  • ⬜Swap de slot executado | produção executa a v2
  • ⬜Autoscale configurado com regras baseadas em CPU
  • ⬜Agenda de backup configurada com conta de armazenamento
  • ⬜Restrições de acesso configuradas no web app

Cenários quebre & conserte​

Cenário a: implantando no slot errado​

# Você implantou a v2 em produção em vez de staging. como reverter?
# Dica: a versão anterior agora está no slot de staging após um swap.
az webapp deployment slot swap \
--resource-group rg-appservice-lab \
--name $APP_NAME \
--slot staging \
--target-slot production

Cenário b: autoscale min > max​

# Tente definir min-count maior que max-count
az monitor autoscale update \
--resource-group rg-appservice-lab \
--name autoscale-web \
--min-count 10 --max-count 3
# Qual erro você recebe?

Cenário c: slots no tier gratuito​

# Crie um plano de tier gratuito e tente adicionar um slot
az appservice plan create -g rg-appservice-lab -n plan-free --sku F1 --is-linux
az webapp create -g rg-appservice-lab --plan plan-free --name free-app-$RANDOM --runtime "NODE:18-lts"
az webapp deployment slot create -g rg-appservice-lab --name free-app-$RANDOM --slot staging
# Qual erro você recebe? quais tiers suportam deployment slots?

Teste seus conhecimentos​

1. Quais tiers do plano do App Service suportam deployment slots?

Mostrar Resposta
TierSlotsDomínios PersonalizadosSSLAutoscale
Free (F1)00❌❌
Shared (D1)0Personalizado❌❌
Basic (B1-B3)0Personalizado✅❌
Standard (S1-S3)5Personalizado✅✅
Premium (P1-P3)20Personalizado✅✅

Deployment slots requerem tier Standard ou superior.

2. O que acontece durante um swap de slot?

Mostrar Resposta
  1. O Azure aplica as configurações do slot de destino (connection strings, app settings marcadas como "slot setting") ao slot de origem.
  2. O Azure aquece o slot de origem enviando uma requisição HTTP para seu caminho raiz.
  3. Se o aquecimento for bem-sucedido, o Azure troca as regras de roteamento | o tráfego agora vai para o slot de origem aquecido.
  4. O código anterior de produção agora está no slot de staging (rollback instantâneo se necessário).

O swap é atômico da perspectiva do usuário | sem tempo de inatividade.

3. Quais configurações de deployment slot são trocadas e quais não são?

Mostrar Resposta

Configurações que SÃO trocadas (seguem o código):

  • App settings (a menos que marcadas como "slot setting"), connection strings, handler mappings, certificados públicos, conteúdo de WebJobs, aplicações virtuais

Configurações que NÃO são trocadas (ficam com o slot):

  • Endpoints de públicação, nomes de domínio personalizados, certificados e bindings TLS/SSL, configurações de escala, configurações de diagnóstico, CORS, integração VNet, identidades gerenciadas, configurações terminando em _EXTENSION_VERSION

4. Qual é a diferença entre scale-up e scale-out?

Mostrar Resposta
  • Scale-up (vertical): Altera o tier/tamanho do plano do App Service | VM maior, mais CPU/RAM. Requer uma breve reinicialização.
  • Scale-out (horizontal): Adiciona mais instâncias do mesmo tamanho. O App Service faz balanceamento de carga entre as instâncias. Pode ser manual ou automático (regras de autoscale). Sem tempo de inatividade.

Limpeza​

# Excluir todos os recursos
az group delete --name rg-appservice-lab --yes --no-wait

# Limpar arquivos locais
rm -rf webapp

echo "Os recursos estão sendo excluídos em segundo plano."