Operar Aplicativos de Contêiner do Azure com segurança: revisões, ciclo de vida, logs, sondas e escala

radio_button_uncheckedshort_text1. Operação contínua de uma carga de IA

Atualizações frequentes de modelos, prompts, dependências e roteamento fazem os serviços de IA mudar rapidamente. Considere uma esteira documental com uma API HTTP para receber PDFs e um worker em segundo plano para OCR e classificação. Ambos executam nos Aplicativos de Contêiner do Azure, e o objetivo é publicar várias vezes ao dia sem encaminhar usuários para uma revisão defeituosa.

Um fluxo confiável conecta identidade do artefato, estado da revisão, controle de tráfego, logs, sinais das sondas e capacidade. Assim, a equipe de plantão pode diagnosticar uma revisão que não fica pronta enquanto a anterior segue atendendo e pode reter versões antigas apenas pelo período exigido para rollback e auditoria.

• Atualizar imagens e controlar ativação, desativação, rollback e limpeza.
• Escolher corretamente entre iniciar, parar, reiniciar e reduzir a zero.
• Investigar falhas de revisão e runtime por logs, sem depender de acesso ao shell.
• Ajustar inicialização, preparação e atividade ao aquecimento do modelo.
• Equilibrar CPU e memória por réplica com limites e regras de escala.

Resumo do tópico

A confiabilidade após a implantação nasce da união entre versões, revisões, observabilidade, sondas e decisões de capacidade em um runbook repetível.

radio_button_uncheckedshort_text2. Tags, digests e atualizações que criam revisões

Uma tag é um nome móvel e conveniente, como dev ou staging. O digest identifica conteúdo imutável. Em produção, prefira o digest para relacionar um incidente ao contêiner e ao build de modelo exatos. Uma tag reutilizada não oferece a mesma rastreabilidade.

Alterações no template - inclusive imagem e configuração de escala - pertencem ao escopo da revisão e geram uma nova revisão imutável. Configurações do aplicativo, como regras de tráfego da entrada, podem alcançar todas as revisões. Depois de atualizar, confira o template registrado pela plataforma.

az containerapp update \
  --name ai-document-api \
  --resource-group rg-ai200-aca \
  --image myregistry.azurecr.io/ai-document-api@sha256:<digest>

az containerapp show \
  --name ai-document-api \
  --resource-group rg-ai200-aca \
  --query properties.template.containers

Resumo do tópico

Use digests auditáveis, reconheça quais mudanças criam revisões e valide o template antes de liberar tráfego.

radio_button_uncheckedshort_text3. Modos de revisão, ativação, tráfego e rollback

No modo de revisão única, a versão anterior permanece ativa até a substituta ser provisionada, atingir a quantidade esperada de réplicas e passar pelas sondas de inicialização e preparação. Se a nova falhar, o tráfego continua na anterior. O modo de várias revisões permite ativar mais de uma versão, dividir tráfego e realizar canário, teste A/B ou implantação azul-verde.

Ativa significa apta a executar e receber tráfego; não significa que todo o tráfego precise chegar nela. Revisões inativas preservam histórico sem manter réplicas. Antes de mudar pesos, confirme integridade e logs e, quando necessário, valide um modelo novo com uma pequena parcela de tráfego.

Resumo do tópico

O modo único automatiza a troca protegida; o múltiplo oferece ativação e divisão de tráfego para entrega progressiva e rollback rápido.

radio_button_uncheckedshort_text4. Inspecionar, desativar e reter revisões

Liste revisões para localizar a versão ativa e a versão com falha. Compare imagem, ambiente, recursos e integridade da suspeita com uma versão saudável. Desative antes de excluir: a desativação encerra suas réplicas e a exposição ao tráfego, mas preserva a configuração como evidência e possível caminho de rollback.

az containerapp revision list \
  --name ai-document-api --resource-group rg-ai200-aca --all -o table

az containerapp revision show \
  --name ai-document-api --resource-group rg-ai200-aca \
  --revision <revision-name>

az containerapp revision deactivate \
  --name ai-document-api --resource-group rg-ai200-aca \
  --revision <revision-name>

Exclua versões obsoletas apenas depois do incidente e da janela de rollback. Por padrão, os Aplicativos de Contêiner do Azure mantêm até 100 revisões inativas e removem as mais antigas ao ultrapassar o limite configurado. Ajuste maxInactiveRevisions conforme auditoria, recuperação e clareza operacional.

Resumo do tópico

Investigue por revisão, desative antes da limpeza destrutiva e documente uma janela de retenção para rollback e evidências.

radio_button_uncheckedshort_text5. Iniciar, parar, reiniciar ou reduzir a zero

Cada ação resolve um problema. Reduzir a zero é automático e orientado por regras, adequado a trabalho intermitente ou baseado em eventos. Parar é uma pausa explícita de todo o aplicativo e garante que réplicas não sejam iniciadas durante uma contenção. Reiniciar recicla réplicas para limpar um estado transitório ou aplicar uma mudança, mas amplia cold starts em serviços que carregam modelos grandes.

Iniciar e parar atuam no aplicativo inteiro; na CLI do Azure atual, o comando de reinício aponta para uma revisão nomeada. Se só uma versão estiver defeituosa, desative ou reinicie aquela revisão. Sempre acompanhe um restart com logs e integridade, pois reciclar o processo pode apenas adiar a falha. O contêiner também deve tratar encerramento gracioso e manter estado durável fora do sistema de arquivos local.

az containerapp stop --name ai-document-api --resource-group rg-ai200-aca
az containerapp start --name ai-document-api --resource-group rg-ai200-aca
az containerapp revision restart \
  --name ai-document-api --resource-group rg-ai200-aca \
  --revision <revision-name>

az containerapp revision list \
  --name ai-document-api --resource-group rg-ai200-aca \
  --query "[].{name:name,active:properties.active,health:properties.healthState}" \
  -o table

Resumo do tópico

Use a ação mais estreita: escala zero para ociosidade, parada para pausa garantida, reinício para estado transitório e controles de revisão para falhas de uma versão.

radio_button_uncheckedshort_text6. Checklist repetível de falhas

Comece nomeando a revisão com falha e comparando a integridade da plataforma com os logs da aplicação. Verifique camadas comuns em ordem fixa para não esconder a causa com reinícios ou mais recursos.

1. Pull da imagem: confirme servidor, digest, identidade ou credencial e autorização AcrPull.
2. Porta e entrada: valide a porta e a interface em que o processo escuta.
3. Configuração: compare variáveis e referências de segredos com a revisão saudável.
4. Sondas: confira tipo, protocolo, caminho, porta, tempos e resposta.
5. Recursos: procure encerramento por falta de memória, limitação de CPU, crash loop e aquecimento prolongado.
6. Dependências e código: só depois da plataforma, investigue exceções e serviços externos.

Resumo do tópico

Identifique a revisão e valide imagem, rede, configuração, sondas, recursos e código em uma sequência consistente.

radio_button_uncheckedshort_text7. Transmitir e reter os logs corretos

Logs de console vêm de stdout e stderr; logs de sistema descrevem a plataforma e as revisões; logs HTTP opcionais mostram entrada, latência e respostas 5xx. A transmissão ao vivo ajuda a reproduzir um crash de inicialização ou uma exceção, enquanto o Log Analytics guarda histórico para consultas. O ambiente precisa ter o destino de logs configurado antes do incidente.

az containerapp logs show \
  --name ai-document-api --resource-group rg-ai200-aca \
  --follow --tail 50

az containerapp logs show \
  --name ai-document-api --resource-group rg-ai200-aca \
  --type system --tail 50

Registre ID de correlação, revisão ou build, tag ou digest, implantação ou versão do modelo, latência total e tempos das dependências. Prefira identificadores e metadados a PDFs, prompts, credenciais ou dados pessoais brutos, mantendo capacidade de diagnóstico sem criar exposição.

ContainerAppConsoleLogs_CL
| where ContainerAppName_s == "ai-document-api"
| where RevisionName_s contains "<revision-name>"
| project TimeGenerated, RevisionName_s, Log_s
| order by TimeGenerated desc

Resumo do tópico

Combine streams de console e sistema com o histórico do Azure Monitor e use logs estruturados que relacionem requisição, revisão, modelo e latência sem conteúdo sensível.

radio_button_uncheckedshort_text8. Diagnosticar um incidente específico de revisão

1. Confirme os nomes da revisão ativa, da mais recente e da que falha.
2. Acompanhe logs de console e sistema enquanto a revisão inicia ou a requisição é reproduzida.
3. Compare imagem, variáveis, segredos, entrada, sondas e recursos com uma revisão saudável.
4. Corrija um único ponto; mudanças no template gerarão outra revisão.
5. Espere provisionamento e sondas, valide latência e erros e só então mova tráfego.
6. Retenha a versão anterior durante a janela de rollback e limpe de acordo com a política.

Mudar uma variável por vez preserva causalidade. Não apague o histórico nem aumente recursos como primeira reação quando a evidência indica variável ausente, porta errada ou caminho incorreto.

Resumo do tópico

Reduza o escopo, reproduza com logs, compare com uma base saudável, corrija um ponto e verifique a próxima revisão antes do tráfego.

radio_button_uncheckedshort_text9. Sondas de inicialização, preparação e atividade

APIs de IA carregam modelos, aquecem caches e conectam dependências. A preparação só deve ter sucesso quando o serviço puder atender. A atividade deve detectar deadlock ou processo irrecuperável, não uma lentidão externa transitória. A plataforma aceita sondas HTTP(S) e TCP; sondas exec não são aceitas e só pode existir uma de cada tipo por contêiner.

properties:
  template:
    containers:
      - name: api
        image: myregistry.azurecr.io/ai-document-api@sha256:<digest>
        probes:
          - type: Startup
            httpGet: { path: /health/startup, port: 8080 }
            periodSeconds: 10
            failureThreshold: 12
          - type: Readiness
            httpGet: { path: /health/ready, port: 8080 }
            initialDelaySeconds: 20
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3
          - type: Liveness
            httpGet: { path: /health/live, port: 8080 }
            initialDelaySeconds: 60
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3

Resumo do tópico

Use inicialização para o aquecimento, preparação para proteger o tráfego e atividade para reciclar processos travados, sempre conforme o comportamento real.

radio_button_uncheckedshort_text10. Diagnosticar sondas sem criar loops de reinício

As causas mais frequentes são porta ou caminho incompatível, endpoint inacessível, protocolo incorreto, timeout menor que o aquecimento ou dependência indisponível. Em sondas HTTP, respostas entre 200 e 399 representam sucesso.

• Alinhe a porta da sonda ao processo e à porta de destino da entrada.
• Exponha endpoints leves e separados quando inicialização, preparação e atividade tiverem critérios distintos.
• Ajuste atraso, período, timeout e limite de falhas com base no tempo medido.
• Não faça a atividade depender de todos os sistemas externos.
• Relacione horário e tipo da falha ao estado da revisão, logs e à experiência Diagnosticar e resolver problemas.

Uma atividade agressiva reinicia o processo antes que o modelo carregue e cria um loop de cold starts. Uma preparação permissiva produz o risco oposto: envia usuários para uma réplica incapaz de atender.

Resumo do tópico

Valide alcance e tempo medido, evite dependências transitórias na atividade e explique cada falha com logs e diagnóstico da revisão.

radio_button_uncheckedshort_text11. Dimensionar CPU e memória por réplica

CPU e memória determinam capacidade e custo unitário. CPU insuficiente causa limitação e picos de latência; memória insuficiente causa encerramentos, reinícios e novos carregamentos de modelo. O custo total combina tamanho, quantidade e tempo de execução das réplicas.

Meça latência da API sob concorrência e vazão do worker, acompanhando CPU, memória, reinícios e preparação. Altere um limite por vez e repita a mesma carga. Uma versão de modelo pode mudar tempo de início, memória e latência, portanto o perfil deve ser revalidado.

az containerapp update \
  --name ai-document-api --resource-group rg-ai200-aca \
  --cpu 1.0 --memory 2Gi

az containerapp update \
  --name ai-document-api --resource-group rg-ai200-aca \
  --min-replicas 1 --max-replicas 10

Resumo do tópico

Escolha recursos pelo gargalo medido, repita testes representativos e reavalie após mudanças relevantes no modelo ou nas dependências.

radio_button_uncheckedshort_text12. Escalar APIs síncronas e workers de formas diferentes

Os Aplicativos de Contêiner do Azure usam limites declarativos e regras baseadas no KEDA para criar ou remover réplicas. HTTP reage a requisições concorrentes; TCP, a conexões; regras personalizadas podem usar CPU, memória, filas, Barramento de Serviço do Azure, Hubs de Eventos do Azure, Apache Kafka, Redis e outras fontes. Mudar a escala cria nova revisão.

Uma API sensível à latência pode manter uma réplica mínima para reduzir cold starts e alinhar concorrência à CPU. Um worker baseado em eventos pode chegar a zero se o trabalho for durável e o encerramento for seguro. Sem entrada, defina regra personalizada ou mínimo, pois a aplicação precisa de um gatilho para despertar. Regras de CPU ou memória não reduzem a zero porque precisam de réplica ativa para medir.

Sondas e escala devem concordar: o aquecimento esperado não deve parecer falha. Réplicas mínimas elevam responsividade e custo base; máximas protegem orçamento e dependências, mas podem limitar vazão.

Resumo do tópico

Mantenha capacidade aquecida para APIs, permita zero para workers duráveis e ajuste KEDA, limites, recursos e sondas como um sistema.

radio_button_uncheckedshort_text13. Laboratório guiado: diagnosticar uma API documental

Use uma assinatura paga do Azure com permissões, CLI do Azure atual e Visual Studio Code; Python 3.12 ou superior é opcional. ACR Tasks pode não executar com créditos gratuitos, portanto confirme a elegibilidade. Trabalhe em grupo de recursos descartável e remova-o ao terminar.

1. Implante uma API documental simulada e registre revisão ativa, FQDN, digest e base saudável.
2. Remova uma variável obrigatória, acompanhe a nova revisão e use logs para localizar e corrigir o erro.
3. Configure uma porta de destino incorreta e compare o processo com a entrada até corrigir.
4. Adicione ou altere a preparação e diferencie aquecimento lento de endpoint incorreto.
5. Consulte o Log Analytics por aplicativo e revisão e monte uma linha do tempo.
6. Aplique a correção, prove a preparação, retenha o rollback e remova apenas evidências obsoletas.

As evidências esperadas são estado das revisões, logs de console e sistema com correlação, configuração corrigida e observação antes/depois. Não registre documentos ou credenciais reais.

Resumo do tópico

O laboratório pratica configuração ausente e entrada incorreta e comprova a solução pelo estado da revisão, logs ao vivo e histórico do Log Analytics.

radio_button_uncheckedshort_text14. Revisão de conhecimentos

Resumo do tópico

O exame privilegia identidade imutável, controle estreito, diagnóstico por evidência, endpoints corretos e recursos ligados a métricas.

radio_button_uncheckedshort_text15. Checklist operacional e referências Microsoft

• Antes: fixe o digest, registre build e modelo, confirme segredos, porta e tempos das sondas.
• Durante: acompanhe provisionamento, sondas, logs, réplicas, latência e erros antes do tráfego.
• No incidente: isole a revisão, preserve evidências, compare a base e mude um ponto.
• Depois: teste rollback, documente causa e sinal, aplique retenção e reavalie recursos e escala.

1. Azure Container Apps revisions
2. Application lifecycle management
3. Application logging
4. Health probes
5. Scaling applications
6. Azure CLI - az containerapp

Resumo do tópico

O runbook deve tornar explícitos identidade, portões de integridade, evidências, rollback, limpeza e revisão de capacidade.