Cron с Docker: запуск периодических задач

Иллюстрация: логотип Docker и контейнеры

Cron можно запускать четырьмя основными способами при работе с Docker: в crontab хоста, внутри контейнера, в отдельном контейнере, или как Kubernetes CronJob.
Для production обычно рекомендуют разделять обязанности (отдельный контейнер для cron) или использовать Kubernetes CronJob — это упрощает масштабирование и исключает дублирование выполнения задач.
В статье — примеры команд, docker-compose-конфигурация, Kubernetes-манифест, чек-листы и карта принятия решения.

Быстрые ссылки

Использование системного crontab
Cron внутри контейнеров
Разделение cron и сервисов приложения
Kubernetes CronJob

Запуск фоновых задач по расписанию — стандартная потребность бэкенд‑сервисов. Раньше это было просто: правишь crontab на сервере и всё. При контейнеризации возникает вопрос, как корректно привязать привычные системные механизмы (cron) к концепциям Docker. Ниже приведены четыре подхода, упорядоченные по степени пригодности для production. Перед началом убедитесь, что у вас установлен Docker и вы собрали Docker-образ вашего приложения.

Использование системного crontab хоста

Самый простой вариант — оставить cron на хосте, где работает Docker Engine. Убедитесь, что cron установлен, и отредактируйте системный crontab как обычно.

Вы можете использовать:

docker exec

чтобы выполнить команду внутри существующего контейнера:

*/5 * * * * docker exec example_app_container /example-scheduled-task.sh

Этот способ работает только если имя контейнера известно заранее. Чаще лучше запускать новый контейнер, который служит исключительно для выполнения задачи:

*/5 * * * * docker run --rm example_app_image:latest /example-scheduled-task.sh

Каждые пять минут системный cron создаст новый Docker-контейнер на основе образа приложения. Docker выполнит /example-scheduled-task.sh внутри контейнера, а контейнер будет удалён (–rm) после завершения скрипта.

Важно

Такой подход прост, но привязывает расписание к конкретному хосту и требует настройки на каждом сервере.
Подходит для локальной разработки и простых деплоев, но не масштабируется и не интегрируется с оркестратором.

Cron внутри контейнеров

Размещение cron в самом образе делает расписание частью артефакта. Это удобнее, потому что любой, кто использует образ, получает настроенный cron «из коробки». Однако это смешивает обязанности контейнера — приложение и демон cron работают одновременно.

Типичный порядок действий:

Создайте файл crontab в кодовой базе:

*/5 * * * * /usr/bin/sh /example-scheduled-task.sh

В Dockerfile установите cron и скопируйте crontab:

RUN apt-get update && apt-get install -y cron

COPY example-crontab /etc/cron.d/example-crontab

RUN chmod 0644 /etc/cron.d/example-crontab && \
    crontab /etc/cron.d/example-crontab

Мы устанавливаем пакет cron, копируем crontab в /etc/cron.d, корректируем права и регистрируем crontab для демона.

Запускать cron нужно при старте контейнера — нельзя делать это через RUN (это выполняется на этапе сборки и не сохраняется в финальном контейнере). Если контейнер используется только для cron, можно добавить в Dockerfile:

ENTRYPOINT ["cron", "-f"]

Если требуется чтобы в контейнере одновременно работал веб‑сервер и cron, создайте entrypoint-скрипт (например init.sh), где сначала запускаете cron, потом основной процесс в foreground:

ENTRYPOINT ["bash", "init.sh"]

А внутри init.sh:

service cron start
exec your-web-server

Плюсы и минусы

Плюс: весь нужный функционал упакован в образ.
Минус: контейнер берет на себя две роли — приложение и планировщик. При масштабировании получим несколько реплик и возможное дублирование задач.

Разделение cron и сервисов приложения

Лучшее практическое правило — одна ответственность на контейнер. Отдельный контейнер для cron позволяет:

Запускать только одну копию планировщика при масштабировании приложения.
Применять разные политики рестарта и ресурсов.
Легче интегрироваться с оркестраторами (Swarm, Kubernetes).

Обычно оба контейнера базируются на одном образе приложения, чтобы cron имел доступ к тем же библиотекам и окружению. Но если задачи тривиальны и не зависят от кода приложения, можно использовать минимальный образ для cron.

Пример с docker-compose — определяем отдельный сервис cron:

version: "3"

services:
  app:
    image: demo-image:latest
    volumes:
      - data:/app-data

  cron:
    image: demo-image:latest
    entrypoint: /bin/bash
    command: ["cron", "-f"]
    volumes:
      - data:/app-data

volumes:
  data:

В этом примере один контейнер обслуживает приложение, второй — запускает cron в фоновом (foreground) режиме. Главное — чтобы образ содержал cron и конфиг crontab.

Почему это важно

При горизонтальном масштабировании приложения у вас не появится N дублирующих cron‑задач.
Можно назначать отдельные ресурсы, лимиты и политики перезапуска.

Советы

Если вам всё же нужно запускать задачи только одной из реплик, используйте механизмы лидера (leader election) или lock‑файлы в общем томе.
Для простых одноразовых задач рассмотрите запуск контейнера через docker run по расписанию на хосте.

Kubernetes CronJob

Если вы используете Kubernetes, у него есть встроенный ресурс CronJob, который значительно упрощает жизнь. Вам не нужно включать cron в образ; вы просто описываете расписание в манифесте.

Пример манифеста:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: my-cron
  namespace: my-namespace
spec:
  schedule: "*/5 * * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-container
            image: my-image:latest
            command: ["/bin/bash", "/my-cron-script.sh"]
          restartPolicy: OnFailure

Примените этот манифест в кластер, и Kubernetes будет периодически создавать Job, который запустит контейнер и выполнит /my-cron-script.sh.

Параметры поведения

schedule: стандартная cron-строка.
concurrencyPolicy: Allow (по умолчанию), Forbid (не запускать параллельно), Replace (заменять запущенную задачу новой).

Преимущества

Не нужен cron внутри образа.
Kubernetes сам создаёт и удаляет поды по расписанию.
Легко смотреть логи через kubectl и управлять повторными запусками.

Ограничения

CronJob — бета/GA в разных версиях Kubernetes; проверяйте совместимость с вашей версией.

Когда какой подход выбирать — карта принятия решения

flowchart TD
  A[Нужны плановые задачи при использовании Docker?] --> B{Используете Kubernetes?}
  B -- Да --> C[Используйте CronJob]
  B -- Нет --> D{Нужно масштабирование и отказоустойчивость?}
  D -- Да --> E[Выделенный cron-контейнер + orchestrator]
  D -- Нет --> F{Просто локальная dev среда?}
  F -- Да --> G[crontab хоста — быстро и просто]
  F -- Нет --> H[Cron внутри образа — удобно, но смешивает обязанности]

Практические рекомендации и чек-листы по ролям

Чек-лист для инженера DevOps:

Оценить, сколько копий приложения будет работать в production.
Решить, должна ли задача выполняться единожды или на каждой реплике.
Если задачи критичны — использовать отдельный cron-контейнер или Kubernetes CronJob.
Настроить мониторинг и алёрты на провал cron‑задач.
Обеспечить idempotency (можно запускать задачу несколько раз без побочных эффектов).

Чек-лист для разработчика:

Упаковать все зависимости скрипта в образ.
Сделать скрипты аккуратными: логирование в stdout/stderr, корректный код возврата.
Добавить периодические тесты, которые симулируют запуск cron-скриптов.

Чек-лист для владельца продукта:

Уточнить требования к SLA для плановых задач.
Определить допустимое перекрытие запусков и требования к маршрутизации ошибок.

Мини‑методология развертывания cron в окружении Docker

Разработайте и протестируйте скрипт локально с тем же образом, что и в production.
Выберите модель: host-cron / in-image / sidecar-cron / k8s-cronjob.
Подготовьте образ: включите зависимости, добавьте конфигурацию crontab (если нужно).
Настройте CI: сборка образа и прогон smoke-теста, который запускает cron-скрипт вручную.
Разверните в staging, проверьте выполнение и логи.
В production включите мониторинг и alerting.

Контрпримеры и куда это не годится

Если у вас многокластерная система без общего хранилища, запуск cron на хосте приведёт к рассинхронизации расписаний.
Если задача меняет внешнее состояние (банк, биллинг), запускать её параллельно в нескольких репликах опасно — нужна синхронизация и механизмы дедупликации.
В серверах без Docker (legacy) использование host-cron остаётся правильным решением.

Безопасность и приватность

Не храните секреты в crontab-файлах. Используйте секреты Docker / Kubernetes Secrets.
Логи задач пишите в stdout/stderr или в централизованный лог‑агрегатор, не в локальные файлы контейнера.
Если cron работает с персональными данными, проверьте соответствие требованиям GDPR: минимизируйте время хранения, шифруйте трафик к внешним сервисам.

Факт‑бокс: ключевые моменты

Основные варианты: crontab хоста, cron в образе, отдельный cron-контейнер, Kubernetes CronJob.
Для масштабируемых production-средств рекомендуют отдельный cron-контейнер или CronJob.
Всегда проектируйте задачи как идемпотентные и добавляйте мониторинг.

Критерии приёмки

Скрипт выполняется в целевом окружении по расписанию.
Результаты выполнения логируются и доступны для просмотра.
При одновременном запуске нескольких реплик задачи не дублируют критические операции (или есть защита).
Доступ к секретам организован безопасно.

Примеры отказов и способы их обработки

Задача падает с кодом ошибки: настроить restartPolicy или использовать систему рерунов (например, Kubernetes Job с backoffLimit).
Задача выполняется дольше периода: использовать concurrencyPolicy: Forbid в Kubernetes или механизмы блокировок в общем томе.

Короткое объявление (копия для рассылки, 100–200 слов)

Ввод: В этой заметке описаны проверенные подходы к запуску плановых задач (cron) в окружениях с Docker. Вы узнаете четыре варианта: запуск cron на хосте, установка cron внутри образа, выделение отдельного cron-контейнера и использование Kubernetes CronJob. Для production-релизов мы рекомендуем либо отдельный cron-контейнер, либо встроенный CronJob в Kubernetes — оба подхода улучшают масштабирование и позволяют избежать дублирования задач. В статье — примеры docker-compose, Dockerfile‑фрагменты, Kubernetes-манифест, чек-листы по ролям и карта принятия решения. Следуйте инструкциям по безопасности: используйте секреты и централизованное логирование.

Резюме

Хостовый crontab прост, но не масштабируется.
Cron внутри образа удобен, но смешивает обязанности.
Отдельный cron-контейнер — хороший компромисс для Docker Compose / Swarm.
Kubernetes CronJob — наилучший вариант для кластеров.

Важно

Всегда делайте задачи идемпотентными и добавляйте мониторинг.
Используйте отдельный контейнер или k8s CronJob для production, чтобы избежать дублирования запусков.