Skip to main content

Laboratório Hands-on Guiado: AZ-104 Microsoft Azure Administrator

Cenário​

A TechNova Soluções Ltda. é uma empresa de e-commerce B2B que opera uma plataforma de catálogo e pedidos para distribuidores industriais no Brasil. A infraestrutura atual reside no Azure com uma VNet já provisionada na região Brazil South, um banco de dados Azure SQL e um Key Vault para gerenciamento de segredos. A equipe de DevOps precisa migrar a aplicação web principal, atualmente hospedada em VMs on-premises, para o Azure App Service, garantindo escalabilidade automática, comunicação segura via TLS com domínio personalizado, mecanismos de backup, integração com a VNet existente e um pipeline de deployment com slots de staging.

O objetivo técnico global deste laboratório é provisionar, configurar e validar toda a infraestrutura de App Service necessária para suportar a aplicação web da TechNova em ambiente de produção, cobrindo desde o plano de hospedagem até a estratégia de deployment com zero downtime.

Pré-requisitos​

Antes de iniciar a Fase 1, crie ou confirme a existência dos seguintes recursos:

1. Resource Group

Crie um Resource Group que centralizará todos os recursos do laboratório.

Via Portal​

  1. No portal Azure, pesquise Resource groups na barra de busca superior.
  2. Clique em Create.
  3. Preencha o campo Resource group com rg-technova-lab.
  4. Selecione a região Brazil South.
  5. Clique em Review + create e depois em Create.

Via CLI​

az group create \
  --name rg-technova-lab \
  --location brazilsouth

2. Virtual Network e Subnet

Crie a VNet que será usada para integração de rede do App Service.

Via Portal​

  1. Pesquise Virtual networks e clique em Create.
  2. Preencha Name com vnet-technova-lab.
  3. Selecione o Resource Group rg-technova-lab e a região Brazil South.
  4. Na aba IP Addresses, mantenha o espaço de endereços 10.0.0.0/16.
  5. Adicione uma subnet chamada snet-appservice com intervalo 10.0.1.0/24.
  6. Adicione uma segunda subnet chamada snet-default com intervalo 10.0.0.0/24.
  7. Clique em Review + create e depois em Create.

Via CLI​

az network vnet create \
  --resource-group rg-technova-lab \
  --name vnet-technova-lab \
  --address-prefix 10.0.0.0/16 \
  --subnet-name snet-default \
  --subnet-prefix 10.0.0.0/24 \
  --location brazilsouth

az network vnet subnet create \
  --resource-group rg-technova-lab \
  --vnet-name vnet-technova-lab \
  --name snet-appservice \
  --address-prefix 10.0.1.0/24 \
  --delegations Microsoft.Web/serverFarms

3. Storage Account

Crie uma conta de armazenamento que será usada para armazenar backups do App Service.

Via Portal​

  1. Pesquise Storage accounts e clique em Create.
  2. Selecione o Resource Group rg-technova-lab.
  3. Preencha Storage account name com sttechnovalab (apenas letras minúsculas e números).
  4. Selecione a região Brazil South.
  5. Em Redundancy, selecione LRS.
  6. Clique em Review + create e depois em Create.
  7. Após a criação, acesse o Storage Account, navegue até Containers e crie um container chamado appbackups com acesso Private.

Via CLI​

az storage account create \
  --name sttechnovalab \
  --resource-group rg-technova-lab \
  --location brazilsouth \
  --sku Standard_LRS

az storage container create \
  --name appbackups \
  --account-name sttechnovalab \
  --auth-mode login

Tabela de referência de recursos

RecursoNome no labRegião
Resource Grouprg-technova-labBrazil South
Virtual Networkvnet-technova-labBrazil South
Subnet (App Service)snet-appserviceBrazil South
Subnet (Default)snet-defaultBrazil South
Storage AccountsttechnovalabBrazil South
Storage ContainerappbackupsBrazil South
App Service Planplan-technova-prodBrazil South
App Serviceapp-technova-webBrazil South
Deployment SlotstagingBrazil South

Fases do Laboratório​

Fase 1 — Provisionamento do App Service Plan e do App Service​

Nesta fase você criará a base de hospedagem da aplicação: o App Service Plan que define os recursos computacionais e o App Service que hospedará a aplicação web. Esses recursos serão utilizados e expandidos em todas as fases seguintes.

Objetivos cobertos: Provision an App Service plan, Create an App Service.

Tarefa 1.1 — Criar o App Service Plan​

A TechNova precisa de um plano de hospedagem que suporte os recursos de produção necessários: slots de deployment, backups, certificados personalizados e escalabilidade automática. Você provisionará um App Service Plan no tier Standard S1, que é o tier mínimo que suporta slots e backups.

Via Portal​

  1. No portal Azure, pesquise App Service plans e clique em Create.
  2. Selecione o Resource Group rg-technova-lab.
  3. Preencha Name com plan-technova-prod.
  4. Em Operating System, selecione Linux.
  5. Em Region, selecione Brazil South.
  6. Em Pricing plan, clique em Explore pricing plans e selecione o tier Standard S1.
  7. Clique em Review + create e depois em Create.

Via CLI​

az appservice plan create \
  --name plan-technova-prod \
  --resource-group rg-technova-lab \
  --location brazilsouth \
  --sku S1 \
  --is-linux

Após a criação, o App Service Plan estará ativo com uma instância S1, provendo 1 core, 1.75 GB de RAM e suporte a funcionalidades como deployment slots, backups e escalabilidade. Nenhuma aplicação está associada a ele ainda.

Tarefa 1.2 — Verificar o SKU e os limites do plano​

Antes de criar o App Service, é fundamental confirmar que o plano provisionado realmente suporta os recursos que serão configurados nas fases seguintes. Um erro comum é selecionar um tier Free ou Basic e descobrir a limitação apenas ao tentar configurar slots ou backups.

Via Portal​

  1. Navegue até App Service plans e selecione plan-technova-prod.
  2. No painel Overview, confirme que o Pricing tier exibe Standard S1.
  3. No menu lateral, clique em Scale up (App Service plan).
  4. Observe as funcionalidades incluídas no tier S1: Custom domains/SSL, Auto scale, Staging slots (até 5), Daily backups.
  5. Confirme que o sistema operacional exibido é Linux.

Via CLI​

# Verificar as propriedades do plano
az appservice plan show \
  --name plan-technova-prod \
  --resource-group rg-technova-lab \
  --query "{name:name, sku:sku.name, tier:sku.tier, os:kind, workers:sku.capacity}" \
  --output table

O output esperado deve mostrar o SKU como S1, o tier como Standard e a capacidade como 1. Se o tier estiver como Free ou Basic, exclua o plano e recrie com o SKU correto antes de prosseguir.

Tarefa 1.3 — Criar o App Service​

Com o plano provisionado e validado, agora você criará a aplicação web da TechNova. A aplicação utilizará o runtime Node.js 20 LTS.

Via Portal​

  1. Pesquise App Services e clique em Create e depois em Web App.
  2. Selecione o Resource Group rg-technova-lab.
  3. Preencha Name com app-technova-web. Este nome precisa ser globalmente único; se estiver indisponível, adicione um sufixo numérico (ex: app-technova-web-01) e atualize as referências ao longo do lab.
  4. Em Publish, selecione Code.
  5. Em Runtime stack, selecione Node 20 LTS.
  6. Em Operating System, confirme Linux.
  7. Em Region, confirme Brazil South.
  8. Em App Service Plan, confirme que plan-technova-prod (S1) está selecionado.
  9. Clique em Review + create e depois em Create.

Via CLI​

az webapp create \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --plan plan-technova-prod \
  --runtime "NODE:20-lts"

Após a criação, o App Service estará acessível em https://app-technova-web.azurewebsites.net. Navegue até essa URL no navegador e confirme que a página padrão do Azure é exibida. Isso valida que o App Service está operacional e respondendo a requisições HTTPS.

Tarefa 1.4 — Diagnosticar erro de runtime intencionalmente​

Para exercitar a resolução de problemas, você alterará o runtime para uma versão incompatível, observará o erro e reverterá para o estado funcional.

Via Portal​

  1. No App Service app-technova-web, navegue até Settings > Configuration.
  2. Na aba General settings, altere o Stack para Python e a versão para 3.12.
  3. Clique em Save e confirme.
  4. Aguarde 1 minuto e acesse https://app-technova-web.azurewebsites.net. Observe que a página pode retornar um erro ou comportamento inesperado, pois não há código Python implantado.
  5. Navegue até Diagnose and solve problems e selecione Availability and Performance. Observe os indicadores de erro.
  6. Retorne a Configuration > General settings, altere o Stack de volta para Node 20 LTS.
  7. Clique em Save e confirme.
  8. Acesse novamente a URL e confirme que a página padrão volta a ser exibida.

Via CLI​

# Alterar para runtime incompatível
az webapp config set \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --linux-fx-version "PYTHON:3.12"

# Verificar o status (aguarde ~60 segundos)
curl -s -o /dev/null -w "%{http_code}" https://app-technova-web.azurewebsites.net

# Reverter para o runtime correto
az webapp config set \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --linux-fx-version "NODE:20-lts"

# Confirmar recuperação
curl -s -o /dev/null -w "%{http_code}" https://app-technova-web.azurewebsites.net

Este exercício demonstra o impacto de uma configuração de runtime incorreta e como identificar e corrigir o problema rapidamente. O HTTP status code deve retornar 200 após a reversão.

Fase 2 — Escalabilidade e Certificados TLS​

Nesta fase você configurará a escalabilidade automática do App Service Plan criado na Fase 1 e habilitará certificados TLS para comunicação segura. O App Service app-technova-web e o plano plan-technova-prod criados anteriormente serão expandidos com regras de autoscale e configurações de segurança.

Objetivos cobertos: Configure scaling for an App Service plan, Configure certificates and Transport Layer Security (TLS) for an App Service.

Tarefa 2.1 — Configurar scale out manual​

Antes de configurar autoscale baseado em regras, primeiro ajuste manualmente o número de instâncias para validar que o plano suporta múltiplas instâncias.

Via Portal​

  1. Navegue até o App Service Plan plan-technova-prod.
  2. No menu lateral, clique em Scale out (App Service plan).
  3. Confirme que a opção atual está definida como Manual scale com 1 instância.
  4. Altere o Instance count para 2.
  5. Clique em Save.
  6. Aguarde a conclusão do provisionamento e retorne ao Overview do plano para confirmar que o número de instâncias agora é 2.

Via CLI​

# Escalar manualmente para 2 instâncias
az appservice plan update \
  --name plan-technova-prod \
  --resource-group rg-technova-lab \
  --number-of-workers 2

# Verificar o número de instâncias
az appservice plan show \
  --name plan-technova-prod \
  --resource-group rg-technova-lab \
  --query "sku.capacity" \
  --output tsv

O plano agora opera com 2 instâncias, distribuindo as requisições entre elas. Este é o pré-requisito para validar que o scale out funciona antes de automatizá-lo.

Tarefa 2.2 — Configurar autoscale baseado em regras​

Agora você configurará o autoscale para que o plano escale automaticamente com base na utilização de CPU, simulando o comportamento esperado em produção para a TechNova durante picos de pedidos.

Via Portal​

  1. No App Service Plan plan-technova-prod, clique em Scale out (App Service plan).
  2. Selecione Rules Based (ou Custom autoscale, dependendo da versão do portal).
  3. Na regra padrão (Default scale condition), configure:
    • Minimum instances: 1
    • Maximum instances: 5
    • Default instances: 2
  4. Clique em Add a rule para criar a regra de scale out:
    • Metric source: Current resource (plan-technova-prod)
    • Metric name: CPU Percentage
    • Operator: Greater than
    • Metric threshold: 70
    • Duration (minutes): 5
    • Time grain (minutes): 1
    • Time grain statistic: Average
    • Operation: Increase count by
    • Instance count: 1
    • Cool down (minutes): 5
    • Clique em Add.
  5. Clique em Add a rule novamente para a regra de scale in:
    • Metric name: CPU Percentage
    • Operator: Less than
    • Metric threshold: 30
    • Duration (minutes): 10
    • Operation: Decrease count by
    • Instance count: 1
    • Cool down (minutes): 10
    • Clique em Add.
  6. Clique em Save.

Via CLI​

# Criar autoscale setting
az monitor autoscale create \
  --resource-group rg-technova-lab \
  --name autoscale-technova \
  --resource plan-technova-prod \
  --resource-type Microsoft.Web/serverFarms \
  --min-count 1 \
  --max-count 5 \
  --count 2

# Regra de scale out: CPU > 70% por 5 minutos
az monitor autoscale rule create \
  --resource-group rg-technova-lab \
  --autoscale-name autoscale-technova \
  --condition "CpuPercentage > 70 avg 5m" \
  --scale out 1

# Regra de scale in: CPU < 30% por 10 minutos
az monitor autoscale rule create \
  --resource-group rg-technova-lab \
  --autoscale-name autoscale-technova \
  --condition "CpuPercentage < 30 avg 10m" \
  --scale in 1 \
  --cooldown 10

Com essas regras configuradas, o App Service Plan escalará automaticamente entre 1 e 5 instâncias com base na utilização de CPU. A regra de scale in possui um cooldown maior (10 minutos) para evitar oscilações rápidas (flapping) durante variações temporárias de carga.

Tarefa 2.3 — Verificar e corrigir uma regra de autoscale desbalanceada​

Um erro comum em ambientes de produção é configurar apenas a regra de scale out sem a correspondente regra de scale in, causando acúmulo de instâncias e custos elevados. Nesta tarefa você simulará a remoção da regra de scale in e verificará o impacto.

Via Portal​

  1. Navegue até Monitor > Autoscale e selecione autoscale-technova.
  2. Localize a regra de scale in (CPU < 30%) e clique no ícone de exclusão para removê-la.
  3. Clique em Save.
  4. Observe a notificação de alerta na parte superior do painel. O Azure exibe um aviso informando que existe uma regra de scale out sem a correspondente regra de scale in.
  5. Recrie a regra de scale in com os mesmos parâmetros da Tarefa 2.2, passo 5.
  6. Clique em Save e confirme que o aviso desaparece.

Via CLI​

# Listar regras existentes
az monitor autoscale rule list \
  --resource-group rg-technova-lab \
  --autoscale-name autoscale-technova \
  --output table

# Excluir todas as regras e recriar apenas a de scale out (simulando o erro)
az monitor autoscale rule delete \
  --resource-group rg-technova-lab \
  --autoscale-name autoscale-technova \
  --index 1

# Verificar o aviso ao listar novamente
az monitor autoscale show \
  --resource-group rg-technova-lab \
  --name autoscale-technova \
  --query "profiles[0].rules" \
  --output table

# Recriar a regra de scale in
az monitor autoscale rule create \
  --resource-group rg-technova-lab \
  --autoscale-name autoscale-technova \
  --condition "CpuPercentage < 30 avg 10m" \
  --scale in 1 \
  --cooldown 10

Esta tarefa reforça a importância de manter regras de autoscale balanceadas. Em produção, a ausência de uma regra de scale in pode resultar em custos desnecessários quando o tráfego diminui.

Tarefa 2.4 — Criar um App Service Managed Certificate​

A TechNova precisa garantir que toda comunicação com a aplicação ocorra via TLS. Nesta tarefa você configurará o TLS mínimo e verificará o certificado gerenciado padrão do domínio *.azurewebsites.net.

Via Portal​

  1. Navegue até o App Service app-technova-web.
  2. No menu lateral, clique em Settings > Certificates.
  3. Na aba Managed certificates, observe que o certificado para app-technova-web.azurewebsites.net já é gerenciado automaticamente pelo Azure.
  4. Navegue até Settings > Configuration > aba General settings.
  5. Localize a seção Platform settings.
  6. Em Minimum inbound TLS version, altere para 1.2.
  7. Em HTTPS Only, confirme que está definido como On. Se estiver Off, altere para On.
  8. Clique em Save.

Via CLI​

# Definir TLS mínimo como 1.2
az webapp config set \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --min-tls-version 1.2

# Habilitar HTTPS Only (redireciona HTTP para HTTPS)
az webapp update \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --set httpsOnly=true

# Verificar as configurações
az webapp config show \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --query "{minTlsVersion:minTlsVersion, httpsOnly:httpsOnly}" \
  --output table

Após essa configuração, qualquer tentativa de conexão HTTP será automaticamente redirecionada para HTTPS, e conexões TLS inferiores a 1.2 serão rejeitadas. Teste acessando http://app-technova-web.azurewebsites.net no navegador e observe o redirecionamento automático para HTTPS.

Tarefa 2.5 — Testar rejeição de TLS 1.0/1.1​

Para validar que a configuração de TLS mínimo está funcionando, você tentará uma conexão forçando uma versão TLS inferior.

Via CLI​

# Tentar conexão com TLS 1.0 (deve falhar)
curl -v --tls-max 1.0 https://app-technova-web.azurewebsites.net 2>&1 | grep -E "SSL|error|alert"

# Tentar conexão com TLS 1.1 (deve falhar)
curl -v --tls-max 1.1 https://app-technova-web.azurewebsites.net 2>&1 | grep -E "SSL|error|alert"

# Tentar conexão com TLS 1.2 (deve funcionar)
curl -v --tlsv1.2 https://app-technova-web.azurewebsites.net 2>&1 | grep "HTTP/"

Via Portal​

  1. Acesse https://app-technova-web.azurewebsites.net no navegador.
  2. Clique no ícone de cadeado na barra de endereço.
  3. Verifique os detalhes do certificado e confirme que a conexão utiliza TLS 1.2 ou superior.

As conexões com TLS 1.0 e 1.1 devem ser recusadas com erro de handshake SSL. A conexão com TLS 1.2 deve retornar HTTP/1.1 200 ou HTTP/2 200, confirmando que a política de TLS mínimo está ativa.

Fase 3 — Domínio Personalizado e Backup​

Nesta fase você mapeará um domínio personalizado ao App Service app-technova-web e configurará backups automáticos utilizando o Storage Account sttechnovalab criado nos pré-requisitos. Os recursos do App Service configurados nas Fases 1 e 2 serão utilizados como base.

Objetivos cobertos: Map an existing custom DNS name to an App Service, Configure backup for an App Service.

Tarefa 3.1 — Mapear um domínio personalizado (usando domínio asn.azurewebsites.net de validação)​

Em um cenário de produção, a TechNova utilizaria um domínio como www.technova.com.br. Neste laboratório, como nem todos possuem acesso a um domínio registrado, você executará o processo de mapeamento utilizando a validação de domínio do Azure. Se você possuir um domínio real, substitua os valores conforme indicado.

Via Portal​

  1. Navegue até o App Service app-technova-web.
  2. No menu lateral, clique em Settings > Custom domains.
  3. Observe o domínio padrão app-technova-web.azurewebsites.net já listado.
  4. Clique em Add custom domain.
  5. Em Domain provider, selecione All other domain services.
  6. No campo Domain, insira o domínio personalizado (ex: www.technova.com.br).
  7. Clique em Validate.
  8. O Azure exibirá os registros DNS necessários:
    • Para um subdomínio (www): um registro CNAME apontando para app-technova-web.azurewebsites.net.
    • Para um domínio raiz: um registro A com o IP do App Service e um registro TXT para verificação.
  9. Anote o Custom Domain Verification ID exibido. Este valor é necessário para criar o registro TXT asuid.www no DNS.
  10. Se você possui acesso ao DNS do domínio, crie os registros indicados no provedor DNS. Caso contrário, clique em Close e prossiga para a próxima tarefa, compreendendo o fluxo necessário.

Via CLI​

# Obter o IP externo do App Service (para registro A de domínio raiz)
az webapp show \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --query "defaultHostName" \
  --output tsv

# Obter o verification ID (para registro TXT)
az webapp show \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --query "customDomainVerificationId" \
  --output tsv

# Após criar os registros DNS no provedor, adicionar o binding:
# az webapp config hostname add \
#   --webapp-name app-technova-web \
#   --resource-group rg-technova-lab \
#   --hostname www.technova.com.br

O mapeamento de domínio personalizado requer que os registros DNS estejam propagados antes da validação. O Azure verifica tanto a posse do domínio (via registro TXT) quanto o roteamento (via CNAME ou A record). Em ambientes reais, a propagação DNS pode levar de minutos a horas.

Tarefa 3.2 — Diagnosticar falha de validação de domínio​

Um cenário adverso comum é a falha de validação quando os registros DNS estão incorretos ou ainda não propagados. Nesta tarefa você simulará esse diagnóstico.

Via Portal​

  1. Navegue até Custom domains no App Service app-technova-web.
  2. Clique em Add custom domain e insira um domínio fictício como webapp.technova-fake.com.
  3. Clique em Validate.
  4. Observe a mensagem de erro exibida. O Azure indica que não encontrou os registros CNAME ou A/TXT esperados.
  5. Analise os campos exibidos:
    • O CNAME record esperado (apontando para app-technova-web.azurewebsites.net).
    • O TXT record esperado (com o verification ID).
  6. Clique em Close sem adicionar o domínio.

Via CLI​

# Tentar adicionar domínio sem registros DNS configurados
az webapp config hostname add \
  --webapp-name app-technova-web \
  --resource-group rg-technova-lab \
  --hostname webapp.technova-fake.com 2>&1 || true

# O erro esperado menciona que o registro CNAME ou TXT não foi encontrado
# Use nslookup para verificar o estado DNS
nslookup -type=CNAME webapp.technova-fake.com || true
nslookup -type=TXT asuid.webapp.technova-fake.com || true

Este exercício demonstra como diagnosticar falhas de validação de domínio. Em produção, as causas mais comuns são: registro CNAME apontando para o endereço errado, ausência do registro TXT de verificação, ou tempo insuficiente de propagação DNS.

Tarefa 3.3 — Configurar backup automático​

A TechNova requer backups diários da aplicação para garantir recuperação em caso de falhas. Você configurará o backup automático do App Service utilizando o container appbackups do Storage Account sttechnovalab.

Via Portal​

  1. Navegue até o App Service app-technova-web.
  2. No menu lateral, clique em Settings > Backups.
  3. Clique em Configure.
  4. Em Backup Storage, clique em Storage not configured (ou no link para configurar).
  5. Selecione o Storage Account sttechnovalab.
  6. Selecione o container appbackups.
  7. Clique em OK.
  8. Em Scheduled backup, altere para On.
  9. Configure o agendamento:
    • Backup every: 1 Day(s)
    • Start time: selecione a hora atual mais 1 hora
    • Retention (Days): 30
  10. Marque a opção Include at least one of the linked databases se desejar incluir bancos associados, ou deixe desmarcada para este lab.
  11. Clique em Save.

Via CLI​

# Obter a SAS URL do container de backup
# Definir expiração para 1 ano
EXPIRY=$(date -u -d "+1 year" +%Y-%m-%dT%H:%MZ)

SAS_URL=$(az storage container generate-sas \
  --account-name sttechnovalab \
  --name appbackups \
  --permissions rwdl \
  --expiry $EXPIRY \
  --auth-mode login \
  --as-user \
  --output tsv)

CONTAINER_URL="https://sttechnovalab.blob.core.windows.net/appbackups?${SAS_URL}"

# Configurar backup automático (diário, retenção de 30 dias)
az webapp config backup update \
  --webapp-name app-technova-web \
  --resource-group rg-technova-lab \
  --container-url "$CONTAINER_URL" \
  --frequency 1d \
  --retain-one-backup true \
  --retention 30

O backup automático captura o conteúdo da aplicação (arquivos em /home), configurações do App Service e, opcionalmente, bancos de dados vinculados. O armazenamento no container appbackups permite recuperação em caso de corrupção de dados ou deploys incorretos.

Tarefa 3.4 — Executar e verificar um backup manual​

Para confirmar que a configuração de backup funciona corretamente, execute um backup manual e verifique o resultado.

Via Portal​

  1. No App Service app-technova-web, acesse Backups.
  2. Clique em Backup Now (ou Create backup).
  3. Aguarde a execução. O status mudará de InProgress para Succeeded.
  4. Após a conclusão, clique no backup listado para ver os detalhes.
  5. Confirme que o tamanho do backup é maior que 0 bytes.
  6. Navegue até o Storage Account sttechnovalab > Containers > appbackups.
  7. Confirme que dois arquivos foram criados: um arquivo .zip com o conteúdo do backup e um arquivo .xml com os metadados.

Via CLI​

# Executar backup manual
az webapp config backup create \
  --webapp-name app-technova-web \
  --resource-group rg-technova-lab \
  --container-url "$CONTAINER_URL"

# Listar backups
az webapp config backup list \
  --webapp-name app-technova-web \
  --resource-group rg-technova-lab \
  --output table

# Verificar arquivos no container
az storage blob list \
  --container-name appbackups \
  --account-name sttechnovalab \
  --auth-mode login \
  --query "[].{Name:name, Size:properties.contentLength}" \
  --output table

O backup manual deve aparecer na lista com status Succeeded. Os arquivos no container confirmam que o mecanismo de backup está operacional e que o App Service possui permissão de escrita no Storage Account.

Fase 4 — Configuração de Rede​

Nesta fase você configurará as opções de rede do App Service app-technova-web para integrá-lo à VNet vnet-technova-lab criada nos pré-requisitos. Isso permitirá que a aplicação acesse recursos privados na VNet, como bancos de dados ou outros serviços internos da TechNova.

Objetivo coberto: Configure networking settings for an App Service.

Tarefa 4.1 — Verificar o estado de rede atual​

Antes de integrar o App Service à VNet, verifique o estado de rede atual para confirmar que nenhuma integração existe e que o tráfego sai pela internet pública.

Via Portal​

  1. Navegue até o App Service app-technova-web.
  2. No menu lateral, clique em Settings > Networking.
  3. Na seção Outbound traffic, observe que VNet integration exibe Not configured.
  4. Na seção Inbound traffic, observe as opções de Access restriction e Private endpoints.
  5. Anote o endereço IP de saída exibido em Outbound addresses. Este é o IP usado quando o App Service se comunica com recursos externos.

Via CLI​

# Verificar IPs de saída atuais
az webapp show \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --query "outboundIpAddresses" \
  --output tsv

# Verificar que não há integração de VNet
az webapp vnet-integration list \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --output table

O comando de listagem de integração VNet deve retornar uma lista vazia, confirmando que o App Service não está integrado a nenhuma VNet neste momento.

Tarefa 4.2 — Integrar o App Service à VNet​

Agora você integrará o App Service à subnet snet-appservice da VNet vnet-technova-lab, permitindo que o tráfego de saída da aplicação seja roteado pela VNet.

Via Portal​

  1. No App Service app-technova-web, navegue até Settings > Networking.
  2. Na seção Outbound traffic, clique em VNet integration.
  3. Clique em Add VNet.
  4. Selecione a VNet vnet-technova-lab.
  5. Selecione a subnet snet-appservice.
  6. Clique em OK.
  7. Aguarde a conclusão da integração. O status deve mudar para Connected.

Via CLI​

# Integrar o App Service à VNet
az webapp vnet-integration add \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --vnet vnet-technova-lab \
  --subnet snet-appservice

# Verificar a integração
az webapp vnet-integration list \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --output table

Após a integração, o tráfego de saída do App Service para endereços na faixa 10.0.0.0/16 será roteado pela VNet em vez de pela internet pública. Isso é essencial para acessar recursos como bancos de dados, Key Vaults ou outros serviços com Private Endpoints na mesma VNet.

Tarefa 4.3 — Configurar restrições de acesso de entrada​

Para adicionar uma camada de segurança, você configurará regras de acesso que restringem quais IPs podem alcançar o App Service.

Via Portal​

  1. No App Service app-technova-web, navegue até Settings > Networking.
  2. Na seção Inbound traffic, clique em Access restriction.
  3. Na aba Main site, observe a regra padrão Allow all.
  4. Clique em Add para criar uma regra.
  5. Configure a regra:
    • Name: allow-office-ip
    • Action: Allow
    • Priority: 100
    • Type: IPv4
    • IP Address Block: insira seu IP público atual (pesquise "what is my IP" em um buscador e use o resultado no formato CIDR, ex: 203.0.113.50/32)
  6. Clique em Add rule.
  7. Verifique que a regra padrão Unmatched rule é Deny. Se não for, altere para Deny.
  8. Clique em Save.

Via CLI​

# Obter seu IP público (substitua pelo seu IP real)
MY_IP=$(curl -s ifconfig.me)

# Adicionar regra de permissão
az webapp config access-restriction add \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --rule-name allow-office-ip \
  --action Allow \
  --ip-address "${MY_IP}/32" \
  --priority 100

# Listar regras
az webapp config access-restriction show \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --output table

Com esta configuração, apenas requisições originadas do IP especificado terão acesso ao App Service. Todas as outras requisições serão bloqueadas pela regra padrão de deny.

Tarefa 4.4 — Testar bloqueio de acesso e reverter​

Para validar que a restrição de acesso funciona, você testará o acesso de um IP diferente e depois removerá a restrição para evitar impacto nas próximas fases.

Via Portal​

  1. Acesse https://app-technova-web.azurewebsites.net de um dispositivo ou rede diferente (ex: rede móvel do celular com Wi-Fi desligado). Alternativamente, use um serviço de teste de URL online.
  2. Confirme que o acesso é bloqueado com um erro 403 Forbidden.
  3. Acesse a mesma URL do IP permitido (sua rede atual) e confirme que retorna 200 OK.
  4. Após a validação, retorne a Access restriction.
  5. Remova a regra allow-office-ip clicando no ícone de exclusão.
  6. Altere a regra Unmatched rule de volta para Allow.
  7. Clique em Save.

Via CLI​

# Testar acesso (deve funcionar do seu IP)
curl -s -o /dev/null -w "%{http_code}" https://app-technova-web.azurewebsites.net

# Remover a regra de restrição
az webapp config access-restriction remove \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --rule-name allow-office-ip

# Confirmar que o acesso público está restaurado
curl -s -o /dev/null -w "%{http_code}" https://app-technova-web.azurewebsites.net

A remoção da restrição restaura o acesso público. Em produção, as regras de acesso seriam mantidas como parte da estratégia de segurança, mas neste laboratório removemos para não interferir nas validações das próximas fases.

Fase 5 — Deployment Slots e Estratégia de Implantação​

Nesta fase final você configurará deployment slots no App Service app-technova-web para habilitar uma estratégia de implantação com staging e zero downtime swap. Todos os recursos das fases anteriores (App Service, plano, rede, certificados) serão utilizados como base.

Objetivo coberto: Configure deployment slots for an App Service.

Tarefa 5.1 — Verificar que o plano suporta deployment slots​

Antes de criar um slot, confirme que o App Service Plan plan-technova-prod está em um tier que suporta deployment slots. O tier Standard permite até 5 slots.

Via Portal​

  1. Navegue até o App Service app-technova-web.
  2. No menu lateral, clique em Deployment > Deployment slots.
  3. Observe a mensagem indicando o número de slots disponíveis (o tier S1 permite até 5 slots).
  4. Confirme que apenas o slot Production existe neste momento.

Via CLI​

# Listar slots existentes
az webapp deployment slot list \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --output table

# Se o comando retornar lista vazia, apenas o slot de produção existe

O resultado deve mostrar que nenhum slot adicional foi criado, confirmando que o App Service possui apenas o slot de produção padrão.

Tarefa 5.2 — Criar o slot de staging​

A TechNova utiliza uma estratégia de deployment blue-green, onde novas versões são implantadas no slot de staging, validadas e depois trocadas para produção. Crie o slot de staging.

Via Portal​

  1. No App Service app-technova-web, acesse Deployment > Deployment slots.
  2. Clique em Add Slot.
  3. Preencha Name com staging.
  4. Em Clone settings from, selecione app-technova-web para copiar as configurações do slot de produção.
  5. Clique em Add.
  6. Após a criação, o slot aparecerá na lista como app-technova-web/staging.
  7. Clique no slot staging para acessá-lo. Observe que ele possui uma URL própria: https://app-technova-web-staging.azurewebsites.net.
  8. Acesse essa URL no navegador e confirme que está acessível.

Via CLI​

# Criar slot de staging clonando configurações da produção
az webapp deployment slot create \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --slot staging \
  --configuration-source app-technova-web

# Verificar a URL do slot
az webapp show \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --slot staging \
  --query "defaultHostName" \
  --output tsv

# Testar acesso ao slot
curl -s -o /dev/null -w "%{http_code}" https://app-technova-web-staging.azurewebsites.net

O slot de staging agora existe como uma instância independente do App Service, com sua própria URL e configurações. Ele compartilha o mesmo App Service Plan plan-technova-prod.

Tarefa 5.3 — Configurar slot settings (configurações fixas ao slot)​

Em muitos cenários, certas configurações devem permanecer fixas em um slot e não acompanhar a aplicação durante um swap. Por exemplo, a connection string do banco de staging não deve ir para produção. Configure uma app setting como slot setting.

Via Portal​

  1. Acesse o App Service app-technova-web (slot de produção).
  2. Navegue até Settings > Environment variables.
  3. Clique em Add na aba App settings.
  4. Preencha Name com ENVIRONMENT e Value com production.
  5. Marque a caixa Deployment slot setting (isso fixa o valor ao slot).
  6. Clique em Apply e depois em Save.
  7. Agora, acesse o slot staging (no painel de Deployment slots, clique em staging).
  8. Navegue até Settings > Environment variables.
  9. Clique em Add.
  10. Preencha Name com ENVIRONMENT e Value com staging.
  11. Marque a caixa Deployment slot setting.
  12. Clique em Apply e depois em Save.

Via CLI​

# Configurar app setting no slot de produção (fixo ao slot)
az webapp config appsettings set \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --settings ENVIRONMENT=production \
  --slot-settings ENVIRONMENT

# Configurar app setting no slot de staging (fixo ao slot)
az webapp config appsettings set \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --slot staging \
  --settings ENVIRONMENT=staging \
  --slot-settings ENVIRONMENT

A marcação como Deployment slot setting garante que durante um swap, a variável ENVIRONMENT permanece com o valor production no slot de produção e staging no slot de staging, independentemente do código que está em cada slot.

Tarefa 5.4 — Executar swap e validar a troca​

Agora execute o swap entre os slots de staging e produção. Como ambos os slots possuem o mesmo código base neste momento, o foco é validar que o processo de swap funciona e que as slot settings permanecem fixas.

Via Portal​

  1. No App Service app-technova-web, acesse Deployment > Deployment slots.
  2. Clique em Swap.
  3. Em Source, confirme staging.
  4. Em Target, confirme production.
  5. Revise a seção Config Changes Preview. Observe que a variável ENVIRONMENT é listada como Slot setting e não será trocada.
  6. Clique em Swap para executar.
  7. Aguarde a conclusão. O swap executa um warm-up do slot de staging antes de redirecionar o tráfego.
  8. Após a conclusão, acesse https://app-technova-web.azurewebsites.net e confirme que está acessível.

Via CLI​

# Executar swap
az webapp deployment slot swap \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --slot staging \
  --target-slot production

# Verificar que as slot settings permaneceram fixas
az webapp config appsettings list \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --query "[?name=='ENVIRONMENT'].{Name:name, Value:value, SlotSetting:slotSetting}" \
  --output table

az webapp config appsettings list \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --slot staging \
  --query "[?name=='ENVIRONMENT'].{Name:name, Value:value, SlotSetting:slotSetting}" \
  --output table

O resultado deve mostrar que após o swap, o slot de produção ainda possui ENVIRONMENT=production e o slot de staging ainda possui ENVIRONMENT=staging. Isso confirma que as slot settings funcionam como esperado e que o swap foi executado com sucesso.

Tarefa 5.5 — Simular rollback via swap reverso​

Suponha que a nova versão implantada em produção apresentou um bug crítico. O rollback é executado simplesmente repetindo o swap, pois o código anterior agora está no slot de staging.

Via Portal​

  1. No App Service app-technova-web, acesse Deployment > Deployment slots.
  2. Clique em Swap novamente.
  3. Confirme Source como staging e Target como production.
  4. Clique em Swap.
  5. Após a conclusão, acesse a URL de produção e confirme a operação normal.

Via CLI​

# Rollback via swap reverso
az webapp deployment slot swap \
  --name app-technova-web \
  --resource-group rg-technova-lab \
  --slot staging \
  --target-slot production

# Confirmar que a aplicação está funcional
curl -s -o /dev/null -w "%{http_code}" https://app-technova-web.azurewebsites.net

O swap reverso restaura o estado anterior de produção em segundos, sem necessidade de re-deploy. Esta é uma das maiores vantagens da estratégia de deployment slots: o rollback é instantâneo e não requer pipeline de CI/CD.

Validação Final​

Verifique os seguintes critérios para confirmar que todas as fases do laboratório foram executadas corretamente:

Critério 1: App Service Plan e App Service operacionais

Navegue até o App Service Plan plan-technova-prod e confirme que o tier é Standard S1 e que o App Service app-technova-web está listado em Apps. No portal, acesse App Service plans > plan-technova-prod > Apps. Alternativamente, execute az appservice plan show --name plan-technova-prod --resource-group rg-technova-lab --query "sku.name" e confirme o retorno S1.

Critério 2: Autoscale configurado com regras balanceadas

Navegue até Monitor > Autoscale e selecione autoscale-technova. Confirme que existem duas regras: uma de scale out (CPU > 70%) e uma de scale in (CPU < 30%). Os limites devem ser min=1, max=5, default=2. Alternativamente, execute az monitor autoscale show --name autoscale-technova --resource-group rg-technova-lab --query "profiles[0].rules[].metricTrigger.threshold" e confirme os valores 70 e 30.

Critério 3: TLS 1.2 mínimo e HTTPS Only ativos (validação comportamental)

Execute curl -v --tls-max 1.1 https://app-technova-web.azurewebsites.net 2>&1 e confirme que a conexão falha com erro de handshake SSL. Em seguida, execute curl -v --tlsv1.2 https://app-technova-web.azurewebsites.net 2>&1 e confirme que retorna HTTP 200. Acesse http://app-technova-web.azurewebsites.net no navegador e confirme o redirecionamento automático para HTTPS.

Critério 4: Backup configurado e executado com sucesso

No App Service app-technova-web, acesse Backups e confirme que existe ao menos um backup com status Succeeded. Navegue até sttechnovalab > Containers > appbackups e confirme que os arquivos de backup (.zip e .xml) estão presentes.

Critério 5: Deployment slot staging funcional com slot settings fixas

Execute az webapp config appsettings list --name app-technova-web --resource-group rg-technova-lab --query "[?name=='ENVIRONMENT'].value" --output tsv e confirme que retorna production. Execute o mesmo comando com --slot staging e confirme que retorna staging. Acesse https://app-technova-web-staging.azurewebsites.net no navegador e confirme que o slot de staging está acessível.

Cleanup do Ambiente​

Remova todos os recursos criados durante o laboratório para evitar cobranças desnecessárias. A exclusão do Resource Group remove automaticamente todos os recursos filhos.

Via Portal​

  1. No portal Azure, pesquise Resource groups.
  2. Selecione rg-technova-lab.
  3. Clique em Delete resource group.
  4. No campo de confirmação, digite rg-technova-lab.
  5. Clique em Delete.
  6. Aguarde a conclusão da exclusão. O processo pode levar alguns minutos.
  7. Após a conclusão, pesquise novamente Resource groups e confirme que rg-technova-lab não aparece mais na lista.

Via CLI​

# Excluir o Resource Group e todos os recursos filhos
az group delete \
  --name rg-technova-lab \
  --yes \
  --no-wait

# Verificar a exclusão (aguarde alguns minutos)
az group show \
  --name rg-technova-lab 2>&1 || echo "Resource Group excluído com sucesso."

O parâmetro --no-wait libera o terminal imediatamente enquanto a exclusão ocorre em segundo plano. Para confirmar a conclusão, execute o comando az group show após alguns minutos. Se retornar erro indicando que o recurso não foi encontrado, a exclusão foi concluída com sucesso.