← AZ-104: administração Azure em produção
15 / 17 · 40 MIN

Containers: repetição, revisões e promoção

Controla repetição de tarefas e publicação de versões sem confundir readiness com efeitos de negócio.

Política de reinício

Em ACI, escolhe a política segundo o resultado pretendido do processo. Always mantém reinícios mesmo após sucesso. OnFailure expressa repetição depois de saída com erro, adequada a tarefas que devem terminar após sucesso.

Não uses Never como garantia universal de ausência de repetições perante qualquer falha da plataforma. Em todos os casos, o estado do processo não é uma transação distribuída com os sistemas que recebeu ou alterou.

Efeito e checkpoint

Um batch pode escrever uma ordem e falhar antes do checkpoint. Reiniciá-lo não desfaz essa ordem e pode repeti-la. Define identidade estável da operação, deduplicação e reconciliação de estados incertos.

Um código de saída não zero descreve falha do processo, não prova ausência de efeitos. No exercício, identifica a ordem já criada, decide se a repetição é segura e explica o que deve ficar registado para quem recebe o incidente.

Âmbito da alteração

Em Container Apps, revisões são imutáveis. Alterações ao template, como imagem e regras de escala, criam revisão; alterações de configuração de aplicação podem afetar todas as revisões sem criar outra. Mudar um secret exige preparar o reinício das revisões consumidoras para os processos reconhecerem o valor novo.

Não concluas falha apenas porque não surgiu nova revisão. Regista que configuração mudou e em que processos foi efetivamente ativada.

Tráfego e evidência

Single revision mode mantém a revisão anterior até a nova estar pronta. Multiple revision mode permite controlar versões ativas e distribuição. Um label tem URL próprio e dirige pedidos à revisão designada, independentemente das percentagens do URL principal.

Cem pedidos ao label qa não medem a distribuição 90/10 desse URL principal. Escolhe o ponto de entrada segundo a hipótese: verificar uma versão, medir repartição ou aceitar o serviço completo são ensaios diferentes.

NA PRÁTICA

Uma revisão falha readiness enquanto a anterior serve pedidos. Investiga o arranque e as dependências sem atribuir tráfego à versão só porque o deployment existe. Depois valida transações representativas e efeitos externos.

Armadilhas comuns

Evita inferir exactly-once de restart policy, novo processo de secret atualizado ou repartição global de pedidos feitos a um label.

Tópicos relacionados: App Service: slots, capacidade e caminhos · Consultas, recolha e restauro verificável

Leva esta ideia contigo

Relaciona a mudança com o seu âmbito e escolhe evidência que observe a versão e o caminho realmente em causa.

Criar conta

Referências

Azure é uma marca comercial do grupo de empresas Microsoft. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por Microsoft. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.