Как настроить длительную команду Django в Google Cloud Platform - PullRequest
0 голосов
/ 11 января 2020

Я недавно переместил свой сайт в Google Cloud Run.

Проблема в том, что мне также нужно переместить пару заданий cron, которые ежедневно запускают команду Django, внутри контейнера. Каков предпочтительный способ сделать это, если я не хочу платить за полный кластер Kubernetes с постоянно работающими экземплярами узлов?

Я бы хотел, чтобы задача запустилась, а затем развернула сервер, как это делает Cloud Run, когда я получаю входящий запрос. Я просмотрел всю документацию, но у меня возникли проблемы с поиском правильного решения для долго выполняющихся задач внутри контейнеров, которые не требуют базового сервера в Google Cloud.

Может ли кто-нибудь указать мне правильное направление?

1 Ответ

2 голосов
/ 11 января 2020

Облачный прогон предел времени ожидания запроса 15 минут .

Функции облака предел времени ожидания функции 540 секунд .

Для длительных задач вращения вверх и вниз Вычисления экземпляра при необходимости было бы более предпочтительным вариантом.


Пример того, как запланировать, автоматический запуск и остановка Compute Instances хорошо объясняется здесь: Планирование вычислений экземпляры с Cloud Scheduler

Вкратце: фактический запуск / остановка экземпляра выполняется Cloud Functions. Cloud Scheduler в расписании публикует требуемые задачи в очередь Cloud Pub/Sub, которая вызывает эти функции. Ваш код в конце основного лога c также может публиковать sh сообщение для Cloud Pub/Sub для запуска Stop this instance задачи.


Как обработать задачу в Django?

  • это может быть то же самое django приложение запущено с сервером wsgi для обработки входящих запросов (как обычный сайт django), но с увеличенным запросом / время ожидания ответа / других операций, длительный срок службы wsgi ... - в этом случае задание представляет собой обычный http-запрос к django view

  • , это может быть только один сценарий (или django команда управления ) запускается при запуске экземпляра облака, чтобы просто автоматически выполнить одну задачу

  • вас может также потребоваться передать дополнительные аргументы для задачи, в этом случае вы можете опубликовать sh на Cloud Pub/Sub одну Start instance задачу и одну main logic задачу с пользовательскими аргументами и заставить ваш код тянуть с Pub/Sub первый

  • больше django -национальный - используйте Сельдерей и начинайте с сельдерея отдельно Compute Instance


Один из возможных вариантов использования только одного работника Celery без всех других компонентов (например, брокера (нет официальной встроенной поддержки Cloud Pub / Sub)) и pull / pu sh Задачи в / из Cloud Pub / Sub:

  • запуск работника сельдерея с фиктивным посредником файловой системы
  • добавить целевой метод как @periodic_task для запуска, т.е. каждый 30 секунд
  • в начале задачи - подписаться на очередь Cloud Pub / Sub, проверить новую задачу, получить ее и начать обработку
  • в начале задачи - publi sh в Cloud Pub / Sub результаты и вызов Stop this instance

Также есть Облачные задачи (ограничение по времени: с автозагрузкой - 10 минут , ручной запуск - 24 часа ) в качестве дополнения Cloud Run для асинхронных задач, но в этом случае Cloud Pub / Sub больше подходит.

...