Conceito e mecanismo
Uma atualização de serviço pode avançar por grupos de tarefas e parar perante falhas, conforme a política configurada. Pausa, conclusão e rollback são estados diferentes. Reverter a configuração do serviço não desfaz automaticamente uma migração SQL, uma mensagem enviada ou um ficheiro escrito. O plano da mudança precisa de contemplar esses efeitos. Também distingue o fluxo local de Compose do comando docker stack deploy: a stack usa o formato legado compatível e ignora build. As imagens devem estar construídas e acessíveis aos nós. O sucesso do comando de entrega prova apenas parte do resultado; valida tarefas, configuração efetiva, dependências e uma operação de negócio representativa.
Aplicação guiada
Num projeto fictício com Kubernetes, uma alteração de ConfigMap não atualiza variáveis de ambiente de processos existentes. Planeia substituição controlada dos Pods quando o consumo é por ambiente. Não transfiras essa regra sem análise para ficheiros projetados, que têm outro comportamento de atualização. Readiness determina se a instância está pronta a receber tráfego pelos endpoints correspondentes; não é uma ordem de restart. Liveness pode reiniciar contentores e deve evitar depender indiscriminadamente de serviços externos lentos. Num incidente, confirma qual probe falhou antes de aumentar réplicas. O gestor técnico deve exigir critérios de aceitação que incluam comportamento do serviço, compatibilidade dos dados e reversão ensaiada.
Rollback da imagem concluído, coluna removida: a compatibilidade de dados continua por resolver.
Armadilhas comuns
Stack como build; rollback como recuperação universal; readiness como liveness; ConfigMap como ambiente vivo.
Tópicos relacionados: Swarm: estado desejado, placement e quorum · Imagens reproduzíveis e registry · Daemon, logs e recuperação
Define o que cada mecanismo altera e valida o resultado de negócio.
Referência: Swarm services · DCA Study Guide v1.5 (January2025); current exam listing checked2026-09-30