Alternativa ao Agendador de Tarefas

O Agendador de Tarefas executa comandos. Não entrega um agendamento que se possa operar.

O Dagu instala-se como serviço do Windows e acrescenta o que o Agendador de Tarefas nunca teve: dependências entre jobs, retentativas, logs por passo, histórico de execuções e uma única consola no navegador para todos os servidores, em vez de uma sessão RDP por máquina.

Uma cadeia de jobs dependentes num ficheiro
# nightly-close.yaml
schedule: "0 2 * * *"
max_active_runs: 1
shell: powershell -NoProfile

steps:
  - id: export
    run: .\scripts\Export-Sales.ps1
    retry_policy:
      limit: 2
      interval_sec: 300

  - id: transform
    run: .\scripts\Transform-Sales.ps1
    depends: export

  - id: load
    run: .\scripts\Import-ToCore.ps1
    depends: transform

handler_on:
  failure:
    run: .\scripts\Notify-Failure.ps1

mail_on:
  failure: true

Instala-se como serviço do Windows

Passos em PowerShell, pwsh e cmd.exe

Definições de jobs em YAML versionado

Uma consola web para todos os servidores

At a glance

Agendador de Tarefas e Dagu no Windows Server

Dependências
Dagu

Declaradas com depends; uma falha interrompe os passos seguintes.

Agendador de Tarefas do Windows

Nenhuma. A ordem é aproximada pelas horas de início.

Tratamento de falhas
Dagu

Retentativas, handlers de recuperação e notificação por email.

Agendador de Tarefas do Windows

Um código do último resultado, verificado por uma pessoa.

Definições
Dagu

YAML revisto no Git e implantável em qualquer host.

Agendador de Tarefas do Windows

Configuração gráfica por máquina, exportável como XML.

Visibilidade
Dagu

Consola no navegador com histórico e logs por passo.

Agendador de Tarefas do Windows

Snap-in MMC local e registo de eventos, por servidor.

In depth

Where each tool fits

01

Ordem expressa por horas não é dependência

O Agendador de Tarefas dispara uma tarefa a uma hora. Não existe a noção de uma tarefa esperar por outra, por isso a ordem é expressa estimando durações e afastando as horas de início.

  • A tarefa das 02:30 corre quer a das 02:00 tenha corrido bem ou não, e normalmente consome o que ela deixou
  • depends declara a ordem diretamente, por isso um passo anterior falhado impede o trabalho seguinte em vez de o corromper
  • Jobs genuinamente independentes correm em paralelo em vez de serem afastados por precaução
02

Falhas que se anunciam

Uma tarefa falhada define um código do último resultado e espera que alguém olhe. A maioria das equipas fica a saber na manhã seguinte, pela pessoa a jusante dos dados.

  • retry_policy repete o que é transitório antes de acordar alguém
  • handler_on.failure executa um job de recuperação e mail_on envia a notificação
  • Cada execução guarda stdout e stderr por passo, em vez de um código de retorno e do que chegou ao registo de eventos
03

Definições revisíveis e uma consola acessível

As definições do Agendador vivem na interface de uma máquina. Exportar produz XML que ninguém revê, e verificar dez servidores significa dez sessões remotas.

  • Os workflows são YAML no Git: uma alteração de agendamento passa a ser um pull request e teste e produção partilham a mesma definição
  • A interface web mostra execuções atuais e históricas a partir de qualquer navegador, sem RDP por servidor
  • PowerShell, pwsh e cmd.exe estão disponíveis, por isso os scripts existentes transitam sem alterações

FAQ

Practical questions before adopting Dagu

O Dagu corre como serviço do Windows?

Sim. O instalador PowerShell pode registá-lo como serviço do Windows através de um wrapper WinSW com versão fixada: arranca com a máquina e é visível no Get-Service como qualquer outro serviço. Há binários Windows para amd64, 386 e arm64.

Os meus scripts PowerShell e batch continuam a funcionar?

Sim. Um passo executa o comando via PowerShell, pwsh ou cmd.exe, escolhido por workflow ou por passo. Sem shell configurada, o Dagu prefere PowerShell, depois pwsh, depois cmd.exe. Os scripts são chamados como o Agendador de Tarefas os chamava.

Um só Dagu consegue gerir jobs em vários servidores Windows?

Sim, de duas formas. Os workers podem correr noutras máquinas e receber trabalho de um coordinator, e os nós remotos permitem que uma interface web alterne entre instalações Dagu separadas. Em ambos os casos a consola é um navegador e não um ambiente de trabalho remoto.

Que versões do Windows são suportadas?

Windows Server 2019 e posterior é o alvo seguro. Versões mais antigas sem AF_UNIX continuam a executar workflows, mas o socket de estado em direto e de controlo de paragem fica indisponível, pelo que o Dagu regista um aviso e continua sem ele.

Next step

Start with one workflow.

Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.