Fundamentação Teórica: Create an App Service

1. Intuição Inicial

Imagine que você desenvolveu um aplicativo web e precisa colocá-lo na internet. Sem um serviço gerenciado, você precisaria provisionar uma VM, instalar o sistema operacional, configurar o servidor web (IIS, Nginx, Apache), instalar o runtime da sua linguagem, configurar certificados SSL, monitorar atualizações de segurança do servidor, e muito mais, tudo antes de fazer o deploy da sua aplicação.

O Azure App Service elimina essa complexidade. Você foca exclusivamente no seu código e nas configurações da sua aplicação. A Microsoft gerencia o servidor web, o runtime, os patches de segurança, a disponibilidade da plataforma e a infraestrutura física. Você faz o deploy do código e ele simplesmente funciona em uma URL pública.

Um App Service é o objeto que representa sua aplicação dentro do App Service Plan: é onde você configura qual runtime usar, quais variáveis de ambiente sua aplicação precisa, regras de autorização, domínios customizados, e onde você implanta seu código ou container.

2. Contexto

O ecossistema Azure App Service

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Por que App Service existe

O App Service existe porque a maioria das aplicações web compartilha requisitos comuns de infraestrutura: servidor HTTP, TLS/SSL, load balancing, healthchecks, logging e monitoramento. Gerenciar isso individualmente para cada aplicação é repetitivo, propenso a erros e caro em tempo de engenharia.

O App Service é uma plataforma PaaS (Platform as a Service): você gerencia o quê roda (seu código e configuração), a Microsoft gerencia onde e como roda (infraestrutura, patches, escalabilidade da plataforma).

O que depende do App Service

App Service Plan: infraestrutura obrigatória onde o App Service é hospedado
Deployment methods: código chega ao App Service via Git, FTP, Azure DevOps, GitHub Actions, ZIP deploy, etc.
Custom Domains e SSL: domínios customizados e certificados gerenciados pelo App Service
VNet Integration: para acesso a recursos em redes privadas
Managed Identity: para acesso seguro a outros serviços Azure sem credenciais

3. Construção dos Conceitos

3.1 O que um App Service configura

Um App Service é um objeto com muitas propriedades configuráveis. As mais importantes são:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.2 App Settings e Connection Strings

App Settings são variáveis de ambiente injetadas no runtime da aplicação. São a forma correta de passar configurações (URLs de APIs externas, chaves de funcionalidades, parâmetros de configuração) para o app sem hardcodar no código.

No runtime, App Settings aparecem como variáveis de ambiente:

No .NET: disponíveis via System.Environment.GetEnvironmentVariable("CHAVE")
No Node.js: via process.env.CHAVE
No Python: via os.environ.get("CHAVE")

Connection Strings são um tipo especial de App Setting para strings de conexão de banco de dados. Elas recebem um prefixo automático dependendo do tipo:

SQL Azure: SQLAZURECONNSTR_NomeDaChave
SQL Server: SQLCONNSTR_NomeDaChave
MySQL: MYSQLCONNSTR_NomeDaChave
Custom: CUSTOMCONNSTR_NomeDaChave

A diferença prática: Connection Strings são expostas para o app exatamente como App Settings no runtime. A separação é organizacional e permite que o portal exiba e gerencie os dois tipos separadamente.

3.3 Deployment Slots

Um Deployment Slot é uma instância separada do Web App, com sua própria URL, suas próprias configurações e seu próprio código deployado, mas rodando no mesmo App Service Plan.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O Slot Swap troca o código entre dois slots instantaneamente, sem downtime. O staging aquece (warm-up) enquanto o código atual continua servindo produção. Quando o swap acontece, as requisições são redirecionadas para o slot que estava em staging. Se algo der errado, você faz o swap de volta em segundos.

Configurações sticky (slot-specific): algumas configurações não são trocadas no swap. Elas ficam "presas" ao slot. Isso é crucial para que o slot de staging use o banco de dados de staging enquanto produção usa o banco de dados de produção, mesmo após o swap. App Settings e Connection Strings podem ser marcados como slot settings para ficarem fixos ao slot.

3.4 Authentication (Easy Auth)

O App Service tem um módulo de autenticação built-in chamado Easy Auth que pode ser habilitado sem uma linha de código no app. Ele intercepta requisições antes de chegarem ao app e verifica identidade via:

Azure AD (Microsoft Entra ID)
Google
Facebook
GitHub
Twitter/X

Quando habilitado, o Easy Auth injeta headers com informações do usuário autenticado que o app pode consumir.

3.5 Always On

A configuração Always On mantém o processo do app rodando mesmo sem requisições. Sem ela, o App Service pode desligar o processo após um período de inatividade (~20 minutos), causando cold start na próxima requisição.

Disponível apenas em tiers Basic e acima. No tier Free, Always On não está disponível e cold starts são frequentes.

3.6 Diagnostic Logs

Os logs de diagnóstico do App Service têm vários tipos:

Tipo	O que captura	Onde armazenar
Application Logging	Saída de log da aplicação (console.log, logging frameworks)	File System (temporário) ou Blob Storage
Web Server Logging	Logs HTTP de acesso (IIS logs)	File System ou Blob Storage
Detailed Error Messages	Páginas de erro HTTP 4xx e 5xx	File System
Failed Request Tracing	Trace de requisições falhas	File System

File System Logging é temporário: desabilita automaticamente após 12 horas para não lotar o armazenamento do app. Para retenção persistente, use Blob Storage ou Log Analytics via Diagnostic Settings.

4. Visão Estrutural

Ciclo de deploy e swap completo

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Estrutura completa de um App Service

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

Ciclo de vida de um App Service

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Comportamentos não óbvios críticos

Mudar uma App Setting reinicia o app. Sempre que você salva uma mudança em App Settings ou Connection Strings, o App Service reinicia o processo do app para aplicar as novas variáveis de ambiente. Em produção, isso causa um breve momento de indisponibilidade. Use deployment slots para mudar configurações sem afetar produção.

App Settings do portal sobrescrevem variáveis do código. Se sua aplicação tem uma variável DATABASE_URL configurada no código mas também definida como App Setting no portal, o App Setting do portal vence. Isso pode causar confusão quando configurações do código parecem não ter efeito.

O nome do App Service deve ser globalmente único. A URL padrão do app é {nome}.azurewebsites.net. Como esse domínio é compartilhado globalmente, o nome precisa ser único no mundo inteiro. "ecommerce" já estará tomado, mas "ecommerce-minhaempresa-prod" provavelmente não.

Container-based apps requerem restart para puxar nova imagem. Se você usa um container custom com tag latest, o App Service não vai automaticamente puxar uma nova imagem quando o container é atualizado no registry. Você precisa reiniciar o app ou configurar CI/CD para triggar o restart. Para ambientes de produção, evite a tag latest; use tags versionadas.

SCM (Kudu) é uma ferramenta de diagnóstico poderosa. Cada App Service tem um Kudu site acessível em {nome}.scm.azurewebsites.net. Ele oferece: console SSH no container, browser de arquivos do sistema, visualização de logs em tempo real, e ferramentas de diagnóstico. Requer autenticação Azure AD.

Web sockets e HTTP/2 precisam ser habilitados explicitamente. Por padrão, o App Service desabilita Web Sockets e usa HTTP/1.1. Para aplicações de tempo real (chat, notificações ao vivo) ou apps que se beneficiam de HTTP/2 (multiplexing), essas features devem ser habilitadas nas configurações do app.

6. Formas de Implementação

Portal do Azure

Quando usar: criação inicial, exploração de configurações, operações pontuais

Criar App Service via portal:

Portal > App Services > + Create > Web App
Subscription e Resource Group
Name: nome globalmente único
Publish: Code ou Container Image
Runtime stack: selecionar linguagem e versão
Operating System: Linux ou Windows (deve coincidir com o Plan)
Region: mesma região do Plan desejado
App Service Plan: selecionar existente ou criar novo
Aba Deployment: configurar GitHub Actions se desejar CI/CD imediato
Aba Networking: configurar VNet Integration se necessário
Aba Monitoring: habilitar Application Insights
Review + Create

Azure CLI

# Criar Web App básico em um Plan existente
az webapp create \
  --resource-group "rg-webapp" \
  --plan "asp-ecommerce-prod" \
  --name "ecommerce-frontend" \
  --runtime "NODE:20-lts" \
  --deployment-local-git

# Criar Web App Linux com Python
az webapp create \
  --resource-group "rg-webapp" \
  --plan "asp-api-prod" \
  --name "ecommerce-api" \
  --runtime "PYTHON:3.12"

# Criar Web App Windows com .NET
az webapp create \
  --resource-group "rg-webapp" \
  --plan "asp-dotnet-prod" \
  --name "ecommerce-admin" \
  --runtime "DOTNET:8"

# Criar Web App com container customizado (Linux)
az webapp create \
  --resource-group "rg-webapp" \
  --plan "asp-containers-prod" \
  --name "ecommerce-worker" \
  --deployment-container-image-name "myregistry.azurecr.io/worker:v1.5"

# Listar runtimes disponíveis
az webapp list-runtimes --os-type linux --output table
az webapp list-runtimes --os-type windows --output table

# Configurar App Settings
az webapp config appsettings set \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --settings \
    NODE_ENV=production \
    API_URL=https://api.ecommerce.com.br \
    FEATURE_FLAG_CHECKOUT=true

# Ver App Settings atuais
az webapp config appsettings list \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --output table

# Deletar uma App Setting
az webapp config appsettings delete \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --setting-names "FEATURE_FLAG_CHECKOUT"

# Configurar Connection Strings
az webapp config connection-string set \
  --resource-group "rg-webapp" \
  --name "ecommerce-api" \
  --connection-string-type SQLAzure \
  --settings \
    DefaultConnection="Server=sql-ecommerce.database.windows.net;Database=ecomdb;..."

# Criar Deployment Slot
az webapp deployment slot create \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --slot "staging" \
  --configuration-source "ecommerce-frontend"

# Listar slots
az webapp deployment slot list \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --output table

# Fazer slot swap (staging -> production)
az webapp deployment slot swap \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --slot "staging" \
  --target-slot "production"

# Marcar App Setting como slot-specific (não troca no swap)
az webapp config appsettings set \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --slot "staging" \
  --slot-settings \
    DATABASE_URL="mongodb://mongodb-staging.cosmos.azure.com"

# Habilitar Always On
az webapp config set \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --always-on true

# Configurar HTTPS Only (forçar redirect HTTP -> HTTPS)
az webapp update \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --https-only true

# Habilitar Managed Identity System-Assigned
az webapp identity assign \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend"

# Ver o Object ID da Managed Identity (para RBAC)
az webapp identity show \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --query "principalId" \
  --output tsv

# Configurar VNet Integration
az webapp vnet-integration add \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --vnet "vnet-app" \
  --subnet "subnet-webapp"

# Habilitar logs de diagnóstico para File System
az webapp log config \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --application-logging filesystem \
  --level information \
  --web-server-logging filesystem \
  --detailed-error-messages true

# Ver logs em tempo real (log streaming)
az webapp log tail \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend"

# Fazer deploy de ZIP
az webapp deploy \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --src-path "./dist/app.zip" \
  --type zip

# Reiniciar o app
az webapp restart \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend"

# Parar o app
az webapp stop \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend"

# Iniciar o app
az webapp start \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend"

Azure PowerShell

# Criar Web App
New-AzWebApp `
  -ResourceGroupName "rg-webapp" `
  -Name "ecommerce-frontend" `
  -AppServicePlan "asp-ecommerce-prod" `
  -Location "brazilsouth"

# Configurar runtime Linux (após criação)
$app = Get-AzWebApp -ResourceGroupName "rg-webapp" -Name "ecommerce-frontend"
$app.SiteConfig.LinuxFxVersion = "NODE|20-lts"
$app.SiteConfig.AlwaysOn = $true
Set-AzWebApp -WebApp $app

# Configurar App Settings
$appSettings = @{
  "NODE_ENV"    = "production"
  "API_URL"     = "https://api.ecommerce.com.br"
  "FEATURE_NEW" = "true"
}
Set-AzWebApp `
  -ResourceGroupName "rg-webapp" `
  -Name "ecommerce-frontend" `
  -AppSettings $appSettings

# Criar slot
New-AzWebAppSlot `
  -ResourceGroupName "rg-webapp" `
  -Name "ecommerce-frontend" `
  -Slot "staging"

# Swap de slots
Switch-AzWebAppSlot `
  -ResourceGroupName "rg-webapp" `
  -Name "ecommerce-frontend" `
  -SourceSlotName "staging" `
  -DestinationSlotName "production"

# Habilitar Managed Identity
Set-AzWebApp `
  -ResourceGroupName "rg-webapp" `
  -Name "ecommerce-frontend" `
  -AssignIdentity $true

# Ver estado atual do app
Get-AzWebApp -ResourceGroupName "rg-webapp" -Name "ecommerce-frontend" |
  Select-Object Name, State, DefaultHostName, `
    @{N="Runtime"; E={$_.SiteConfig.LinuxFxVersion}}, `
    @{N="AlwaysOn"; E={$_.SiteConfig.AlwaysOn}}

Bicep

// Web App com configurações completas
resource webApp 'Microsoft.Web/sites@2022-09-01' = {
  name: 'ecommerce-frontend'
  location: 'brazilsouth'
  identity: {
    type: 'SystemAssigned'  // Habilita Managed Identity
  }
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true  // Força HTTPS
    siteConfig: {
      linuxFxVersion: 'NODE|20-lts'  // Runtime Linux
      alwaysOn: true
      minTlsVersion: '1.2'
      ftpsState: 'Disabled'  // Desabilita FTP (segurança)
      http20Enabled: true    // Habilita HTTP/2
      appSettings: [
        {
          name: 'NODE_ENV'
          value: 'production'
        }
        {
          name: 'API_URL'
          value: 'https://api.ecommerce.com.br'
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: appInsights.properties.ConnectionString
        }
      ]
      connectionStrings: [
        {
          name: 'DefaultConnection'
          connectionString: '@Microsoft.KeyVault(SecretUri=${kvSecret.properties.secretUri})'
          type: 'SQLAzure'
        }
      ]
    }
  }
}

// Deployment Slot para staging
resource stagingSlot 'Microsoft.Web/sites/slots@2022-09-01' = {
  parent: webApp
  name: 'staging'
  location: 'brazilsouth'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
    siteConfig: {
      linuxFxVersion: 'NODE|20-lts'
      alwaysOn: true
      appSettings: [
        {
          name: 'NODE_ENV'
          value: 'staging'
        }
      ]
    }
  }
}

7. Controle e Segurança

Configurações de segurança essenciais

HTTPS Only: redireciona automaticamente requisições HTTP para HTTPS. Deve ser habilitado em qualquer app de produção.

Minimum TLS Version: define a versão mínima de TLS aceita. O padrão atual é TLS 1.2; evite TLS 1.0 e 1.1 que têm vulnerabilidades conhecidas.

FTPS State: o FTP é um protocolo inseguro. Para apps de produção, configure como Disabled ou FtpsOnly (FTP sobre TLS).

IP Restrictions: permite definir regras de allowlist ou denylist de IPs para acesso ao app e/ou ao SCM (Kudu).

# Configurar IP Restriction: apenas IPs do escritório
az webapp config access-restriction add \
  --resource-group "rg-webapp" \
  --name "ecommerce-admin" \
  --priority 100 \
  --action Allow \
  --ip-address "200.200.200.0/24" \
  --name "escritorio-sp"

# Bloquear todo o resto (regra de deny all)
az webapp config access-restriction add \
  --resource-group "rg-webapp" \
  --name "ecommerce-admin" \
  --priority 2147483647 \
  --action Deny \
  --ip-address "Any" \
  --name "deny-all"

Key Vault References

Em vez de armazenar segredos diretamente em App Settings, use Key Vault References. O App Service resolve a referência em tempo de execução e injeta o valor secreto como variável de ambiente.

# Formato de Key Vault Reference como App Setting:
# @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-password/version)
# ou sem versão (pega sempre a mais recente):
# @Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-password)

az webapp config appsettings set \
  --resource-group "rg-webapp" \
  --name "ecommerce-api" \
  --settings \
    DB_PASSWORD="@Microsoft.KeyVault(VaultName=kv-ecommerce-prod;SecretName=db-password)"

Para Key Vault References funcionar, o App Service precisa ter uma Managed Identity e a identidade precisa ter a role Key Vault Secrets User no Key Vault.

8. Tomada de Decisão

Code vs. Container

Situação	Escolha	Motivo
App em runtime suportado pelo Azure	Code (runtime padrão)	Mais simples, sem overhead de container
Dependências específicas de sistema	Custom Container	Controle total sobre o ambiente
Migração de app legado	Custom Container	Encapsular dependências antigas
Múltiplos componentes no mesmo processo	Custom Container	Docker Compose via App Service
App .NET, Node.js, Python, Java moderno	Code	Runtimes nativos têm ótima integração

Quando usar Deployment Slots

Situação	Abordagem	Motivo
Deploy de código para produção	Slot Staging + Swap	Zero downtime, rollback fácil
Testar configuração nova em prod	Slot com slot settings	Configuração isolada por slot
A/B testing	Múltiplos slots + tráfego split	Dividir tráfego entre slots
Hotfix urgente em produção	Deploy direto ao slot prod	Sem tempo para staging
Tier Basic	Deploy direto	Slots não disponíveis no Basic

App Settings vs. Key Vault References

Dado	Abordagem	Motivo
URL de API externa não sensível	App Setting direto	Simples, sem overhead
String de conexão de banco	Key Vault Reference	Credencial sensível
Chave de API de terceiro	Key Vault Reference	Segredo que não deve aparecer em logs
Flag de feature	App Setting direto	Não é sensível
Certificado privado	Key Vault Reference	Máxima proteção

9. Boas Práticas

Nunca coloque segredos diretamente em App Settings visíveis no portal. Use Key Vault References para toda informação sensível. App Settings são visíveis para qualquer pessoa com acesso Contributor ao App Service, e podem aparecer em logs de auditoria.

Configure Application Insights desde o início. Application Insights fornece telemetria de performance, rastreamento de exceções, métricas de requisições e muito mais. É muito mais difícil troubleshoot problemas retroativamente sem telemetria histórica.

Use slot settings para configurações que variam por ambiente. String de conexão de banco de dados deve ser slot-specific: o slot de staging usa o banco de staging, e não troca para o banco de produção quando você faz o swap.

Habilite HTTPS Only e TLS 1.2 mínimo em todo app de produção. São configurações de segurança básicas que devem ser padrão. Configure via IaC para garantir que nunca sejam esquecidas.

Desabilite FTP em produção. FTP é um protocolo sem criptografia. Se deploy por FTP não é usado, desabilite completamente. Use Git, GitHub Actions, Azure DevOps ou ZIP deploy.

Configure healthcheck endpoint. O App Service tem um caminho de healthcheck configurável. Se o app falhar em responder a esse endpoint, o App Service reinicia automaticamente instâncias não saudáveis. Configure um endpoint /health que verifica a saúde real da aplicação.

# Configurar healthcheck
az webapp config set \
  --resource-group "rg-webapp" \
  --name "ecommerce-api" \
  --health-check-path "/api/health"

10. Erros Comuns

Erro	Por que acontece	Como evitar
App Setting modificado em produção causando downtime	Mudanças em App Settings reiniciam o app	Usar slots e mudar settings no staging, depois swap
Nome do app já em uso globalmente	azurewebsites.net é global	Usar sufixo único como nome-empresa-prod
Container com tag `latest` não atualiza automaticamente	Azure não monitora o registry	Usar CI/CD com tags versionadas e restart automático
App Settings com segredos em texto claro	Facilidade de configuração	Usar Key Vault References sempre para dados sensíveis
Slot swap trocou configuração de banco de dados	Connection string não marcada como slot-specific	Marcar todas as config específicas de ambiente como slot settings
Always On desabilitado causando cold starts	Padrão vem desabilitado	Habilitar Always On em qualquer app de produção (Basic+)
Log streaming mostra erro mas não o detalhe	Application logging não habilitado	Habilitar logs no nível Information ou Verbose
App não responde após deploy de container	Healthcheck falhou mas app ainda está inicializando	Configurar startup probe timeout adequado

O erro mais custoso em produção

Fazer deploy de novo código diretamente para o slot de produção sem usar slots de staging. Se o novo código tem um bug crítico que não apareceu nos testes, você precisa fazer rollback via novo deploy (que leva tempo e pode ter problemas). Com deployment slots, rollback é um único comando de swap que leva segundos.

11. Operação e Manutenção

Diagnóstico e monitoramento

# Ver estado do app
az webapp show \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --query "{Estado: state, URL: defaultHostName, OutboundIPs: outboundIpAddresses}" \
  --output json

# Ver logs em tempo real
az webapp log tail \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend"

# Baixar logs
az webapp log download \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --log-file ./app-logs-$(date +%Y%m%d).zip

# Ver os IPs de saída do app (para whitelist em banco de dados)
az webapp show \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --query "outboundIpAddresses" \
  --output tsv

# Ver todos os App Settings (sem mostrar valores)
az webapp config appsettings list \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --query "[].name" \
  --output table

# Diagnosticar problemas de VNet Integration
az webapp vnet-integration list \
  --resource-group "rg-webapp" \
  --name "ecommerce-frontend" \
  --output table

Limites importantes

Recurso	Free	Basic	Standard	Premium v3
Armazenamento do app	1 GB	10 GB	50 GB	250 GB
CPU por dia	60 min	Ilimitado	Ilimitado	Ilimitado
Deployment Slots	0	0	5	20
Custom Domains	0	500	500	500
VNet Integration	Não	Não	Sim	Sim
Always On	Não	Sim	Sim	Sim
Auto Scale	Não	Manual	Sim	Sim

12. Integração e Automação

GitHub Actions para deploy contínuo

# .github/workflows/deploy.yml
name: Deploy to Azure App Service

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      - name: Install and Build
        run: |
          npm ci
          npm run build
      
      - name: Deploy to Staging Slot
        uses: azure/webapps-deploy@v3
        with:
          app-name: 'ecommerce-frontend'
          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE_STAGING }}
          slot-name: 'staging'
          package: './dist'
      
      - name: Swap Staging to Production
        uses: azure/CLI@v2
        with:
          inlineScript: |
            az webapp deployment slot swap \
              --resource-group rg-webapp \
              --name ecommerce-frontend \
              --slot staging \
              --target-slot production

Integration com Application Insights via Bicep

// Application Insights para monitoramento do app
resource appInsights 'Microsoft.Insights/components@2020-02-02' = {
  name: 'appi-ecommerce-prod'
  location: 'brazilsouth'
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: logAnalyticsWorkspace.id
  }
}

// Web App com Application Insights configurado
resource webApp 'Microsoft.Web/sites@2022-09-01' = {
  name: 'ecommerce-frontend'
  location: 'brazilsouth'
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      appSettings: [
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: appInsights.properties.ConnectionString
        }
        {
          name: 'ApplicationInsightsAgent_EXTENSION_VERSION'
          value: '~3'  // Habilita auto-instrumentation sem modificar código
        }
      ]
    }
  }
}

13. Resumo Final

Pontos essenciais:

Um App Service é uma aplicação web hospedada em um App Service Plan; você gerencia o código e configurações, a Microsoft gerencia o servidor
App Settings são variáveis de ambiente injetadas no runtime; mudanças causam reinicialização do app
Deployment Slots permitem deploy de código em um slot separado (staging) e depois fazer slot swap para produção sem downtime
Slot Settings marcam App Settings e Connection Strings como específicas do slot, impedindo que troquem durante o swap
Always On mantém o processo do app ativo; sem ele, cold starts acontecem após inatividade; disponível apenas em Basic e acima
O nome do App Service compõe a URL {nome}.azurewebsites.net que deve ser globalmente único

Diferenças críticas:

App Settings vs. Connection Strings: Connection Strings recebem prefixos automáticos (SQLAZURECONNSTR_, etc.) e são gerenciadas separadamente no portal, mas ambas chegam ao app como variáveis de ambiente
Code vs. Container: Code usa runtimes gerenciados pela Microsoft; Container permite qualquer ambiente mas você gerencia a imagem
Slot Settings vs. App Settings normais: Slot settings ficam "presos" ao slot durante swaps; App Settings normais são trocados com o código durante o swap
File System Logging vs. Blob Logging: File System é temporário (desabilita em 12h); Blob é persistente para retenção longa

O que precisa ser lembrado para o AZ-104:

Deployment Slots estão disponíveis a partir do tier Standard (5 slots) e Premium v3 (20 slots); não existem no Basic
Key Vault References em App Settings requerem Managed Identity com role Key Vault Secrets User
az webapp log tail para streaming de logs em tempo real
az webapp deployment slot swap --slot staging --target-slot production para fazer swap
Configurações marcadas como slot settings não são trocadas durante o swap; permanecem no slot onde foram configuradas
HTTPS Only e TLS 1.2 mínimo são configurações de segurança que devem ser padrão em produção
O SCM (Kudu) está em {nome}.scm.azurewebsites.net e oferece acesso SSH ao container, browser de arquivos e diagnósticos

1. Intuição Inicial​

2. Contexto​

O ecossistema Azure App Service​

Por que App Service existe​

O que depende do App Service​

3. Construção dos Conceitos​

3.1 O que um App Service configura​

3.2 App Settings e Connection Strings​

3.3 Deployment Slots​

3.4 Authentication (Easy Auth)​

3.5 Always On​

3.6 Diagnostic Logs​

4. Visão Estrutural​

Ciclo de deploy e swap completo​

Estrutura completa de um App Service​

5. Funcionamento na Prática​

Ciclo de vida de um App Service​

Comportamentos não óbvios críticos​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Bicep​

7. Controle e Segurança​

Configurações de segurança essenciais​

Key Vault References​

8. Tomada de Decisão​

Code vs. Container​

Quando usar Deployment Slots​

App Settings vs. Key Vault References​

9. Boas Práticas​

10. Erros Comuns​

O erro mais custoso em produção​

11. Operação e Manutenção​

Diagnóstico e monitoramento​

Limites importantes​

12. Integração e Automação​

GitHub Actions para deploy contínuo​

Integration com Application Insights via Bicep​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

O ecossistema Azure App Service

Por que App Service existe

O que depende do App Service

3. Construção dos Conceitos

3.1 O que um App Service configura

3.2 App Settings e Connection Strings

3.3 Deployment Slots

3.4 Authentication (Easy Auth)

3.5 Always On

3.6 Diagnostic Logs

4. Visão Estrutural

Ciclo de deploy e swap completo

Estrutura completa de um App Service

5. Funcionamento na Prática

Ciclo de vida de um App Service

Comportamentos não óbvios críticos

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Bicep

7. Controle e Segurança

Configurações de segurança essenciais

Key Vault References

8. Tomada de Decisão

Code vs. Container

Quando usar Deployment Slots

App Settings vs. Key Vault References

9. Boas Práticas

10. Erros Comuns

O erro mais custoso em produção

11. Operação e Manutenção

Diagnóstico e monitoramento

Limites importantes

12. Integração e Automação

GitHub Actions para deploy contínuo

Integration com Application Insights via Bicep

13. Resumo Final