Запуск хрон в Elastic Beanstalk

Question

Так у меня есть функциональность в приложении Django Elastic Beanstalk, который работает следующим образом:

• Скачать файл
• Разобрать файл, запустить программу несколько вызовов API, с данными из файла
• обновления базы данных экземпляра EB с новыми данными

В случаях тестирования, где я просто настроить локальные хроны. Я только что вызвал wget по определенному URL-адресу моего приложения Django, и он запустит эту команду.

Моя проблема заключается в том, как справиться с этим в многоуровневом приложении Elastic Beanstalk. Эта команда должна выполнять только один экземпляр моего приложения EB. Я хочу избежать условий гонки в базе данных и избыточных вызовов внешних API из нескольких экземпляров. то есть только один экземпляр должен записывать в базу данных.

Однако, поиск в Google, показывающий, что создание рабочих мест cron неудобно, особенно если вы новичок в EB, как я. Наиболее перспективным методом звучания является метод cron.yaml, но, похоже, не существует примера создания рабочей среды cron в любой точке Интернета из того, что я вижу.

Мое понимание:

• Вы включать cron.yaml файл в корневом каталоге вашего проекта EB.
• Разверните проект
• Задачи cron автоматически настраиваются в рабочей среде (?).
• Определенная вами команда запускается в указанное время (и).

Мой вопрос: как вы убедитесь, что только один экземпляр выполнит эту команду? У меня есть правильная идея о том, как работает cron.yaml или есть что-то, что мне не хватает

Answer 1

Только один экземпляр выполнит команду, потому что задание cron фактически не запускается в демонах cron per-se.

Существует несколько концепций, которые могут помочь вам быстро разглядеть мышление Амазонки.

• Эластичная фасоль должна выбрать экземпляр лидера, из которого должно быть только когда-либо (и это должен быть здоровый экземпляр и т. Д.).
• Рабочая среда распределяет работу через очередь SQS (Simple Queue Service).
• После того, как сообщение было прочитано из очереди, оно считается «в полете», пока рабочий не вернется на 200 или время запроса/не выполнено. В первом сценарии сообщение удаляется, а в последнем сценарии оно возвращается в очередь. (Политики Redrive могут определять, сколько раз сообщение может провалиться до того, как оно будет отправлено в очередь мертвых букв)
• В полете сообщения не могут быть прочитаны снова (если не возвращены).

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

Теперь файл cron.yaml на самом деле просто сообщает руководителю создать сообщение в очереди со специальными атрибутами в указанное в расписании время. Когда он находит это сообщение, он отправляется одному экземпляру только как запрос POST на указанный URL.

Когда я использую Django в рабочей среде, я создаю приложение cron с представлениями, которые соответствуют действию, которое я хочу. Например, если бы я хотел периодически опросить конечную точку Facebook, у меня мог бы быть путь /cron/facebook/poll/, который вызывает функцию poll_facebook() в views.py

Таким образом, если у меня есть cron.yaml, то он будет опросить Facebook один раз в час :

version: 1 
cron: 
- name: "pollfacebook" 
    url: "/cron/facebook/poll/" 
    schedule: "0 * * * *"