Jobs em segundo plano

Boa parte do Studio roda em um agendamento, e não em resposta a uma requisição de usuário: workflows agendados, todos os triggers de polling, syncs de conectores, o outbox, a drenagem de dados e a retenção. Tudo isso é movido por endpoints HTTP que algo externo precisa chamar em intervalos regulares.

Os dois modelos de implantação já incluem um agendador e o habilitam por padrão: o Kubernetes como CronJobs, o Docker Compose como um serviço cron. Os dois autenticam com o CRON_SECRET e usam os mesmos agendamentos.

Autenticação

Todos os endpoints são protegidos pelo CRON_SECRET e o esperam como bearer token:

curl -f -s -S --max-time 60 \
  -H "Authorization: Bearer $CRON_SECRET" \
  https://studio.yourdomain.com/api/schedules/execute

Gere-o como os outros secrets:

openssl rand -hex 32

Aponte o cron para um endereço interno quando possível (o Service dentro do cluster, ou localhost em um nó único). Esses endpoints não deveriam ser acessíveis pela internet; se forem, o CRON_SECRET é a única coisa que os protege.

Os jobs

Kubernetes

Habilitado por padrão. Não há nada a fazer além de definir o CRON_SECRET.

cronjobs:
  enabled: true

Cada job roda um pequeno pod curlimages/curl que chama o Service do app dentro do cluster (não o ingress), com concurrencyPolicy: Forbid para que uma execução lenta nunca se sobreponha a si mesma, e até três retentativas.

Desative individualmente os jobs de que você não precisa — a reconciliação de cobrança é o caso mais óbvio em uma instalação auto-hospedada:

cronjobs:
  jobs:
    reconcileBillingSeats:
      enabled: false

Verifique se estão rodando:

kubectl get cronjobs -n studio
kubectl get jobs -n studio --sort-by=.metadata.creationTimestamp | tail
kubectl logs -n studio job/<job-name>

Um CronJob cujo LAST SCHEDULE está desatualizado, ou cujos jobs estão falhando, significa que o recurso correspondente está morto. Crie um alerta para isso — veja Observabilidade.

Docker Compose

O serviço cron roda os mesmos jobs nos mesmos agendamentos, então não há nada a configurar além do CRON_SECRET:

CRON_SECRET=$(openssl rand -hex 32)

Sem ele, o serviço cron registra no log exatamente o que definir — inclusive um valor recém-gerado — e encerra, deixando o resto da stack em pé. Os agendamentos ficam em docker/crontab e espelham um a um o cronjobs.jobs de helm/studio/values.yaml.

O serviço roda o supercronic em vez da imagem do app: ele registra a saída de cada job no log do contêiner, repassa o SIGTERM para que docker compose stop seja gracioso, e não inicia uma iteração enquanto a anterior ainda está em execução.

docker compose -f docker-compose.prod.yml logs -f cron

Uma linha de log saudável se parece com isto:

level=info msg=starting iteration=0 job.schedule="*/1 * * * *"
level=info msg="job succeeded" iteration=0

Para descartar um job de que você não precisa, comente a linha dele em docker/crontab e reinicie o serviço.

Verificando

Crie um workflow com um trigger Schedule definido para cada minuto, faça o deploy e acompanhe a visão Logs. Uma execução deve aparecer em cerca de 2 minutos. Se nada aparecer:

1. Verifique os logs do próprio agendador — docker compose logs cron, ou kubectl get cronjobs -n studio para conferir um LAST SCHEDULE recente.
2. Confirme que o app e o agendador compartilham o mesmo CRON_SECRET. Uma divergência aparece como 401 no log do agendador.
3. Um 202 significa que o endpoint aceitou a chamada; não confirma que havia um agendamento a executar, então confira a visão Logs.

Concorrência

O volume de execuções agendadas é limitado por instância do app por:

Só aumente o limite de agendamentos junto com folga de memória: as execuções concorrentes rodam no processo do app, então a vazão é limitada pela memória do pod antes de ser limitada por esse número.