Para os apressados a solução é rodar o cron em foreground. Dessa forma ele segura o container e ele não morre de cara.

ENTRYPOINT ["cron", "-f"]

Para quem curte uma solução mais completa abaixo está o Dockerfile que usei para resolver essa tarefa. No container deveria haver dois scripts, o primeiro que consultava uma API e retornava uma lista contendo um GUID, data da ultima alteração e a periodicidade que esse GUID deveria ser chamado. O segundo script que era chamado pelo cron passando o GUID respeitando a periodicidade definida.

Assim o primeiro script, deveria acessar uma API a cada 15 minutos, verificar localmente se aqueles GUID recebidos já tinham seus respectivos arquivos cron gerados. A solução foi que para cada GUID recebido criariamos arquivos na pasta do cron.d no formato abaixo.

#/etc/cron.d/run_primeiro_script
*/15 * * * * root /app/primeiro_script.py

O segundo script precisa ser chamado dada uma periodicidade e passando um ID como parâmetro.

#/etc/cron.d/426c3f18-8f87-4ca7-98a9-aaa865ae46d1
*/5 * * * * root /app/segundo_script.py --id 426c3f18-8f87-4ca7-98a9-aaa865ae46d1

O Dockerfile ficou assim.

FROM ubuntu:23.04 AS base

WORKDIR /app
RUN apt-get update && apt-get install -y cron python3
RUN echo "*/15 * * * * root python3 /app/primeiro_script.py > /proc/1/fd/1 2>/proc/1/fd/2" > /etc/cron.d/run_primeiro_script

COPY . .

ENTRYPOINT ["cron", "-f"]

Eu ressalto que como a tarefa do cron é executado em um bash as mensagens da aplicação não saem no bash principal e como consequência não é possível ver essas mensagens no log. Por isso redirecionamos o stdout e o stderr do “primeiro_script.py” para o processo de PID 1 que é o comando executado pelo entrypoint.

Essa é uma solução interessante também para manter o log quando o cron executar scripts, programas e aplicações que tenham muita saída no stdout e que normalmente estivessem rodando em foreground seriam enviados para o log do pod.

The post Docker Cron appeared first on Pereira, Thiago Santos..