Правильный способ запуска команд manage.py после развертывания на Elastic Beanstalk?

Question

Я развертываю приложение Django для EB - мое первое развертывание EB - и я смущен порядком вещей.

Моих команды контейнера таковы:

container_commands: 
    01_migrate: 
    command: "django-admin.py migrate" 
    leader_only: true 
    02_collectstatic: 
    command: "django-admin.py collectstatic --noinput" 
    leader_only: true 

То, что я заметил, однако, заключается в том, что каждый раз, когда я раскрываю эти команды контейнеров выполняются на моем старом кодового. Предположим, что мой текущий код равен app-v1.zip. Я обновляю свой models.py и создаю миграцию. Затем я eb deploy, который создает app-v2.zip. Команда migrate запускается в среде EB, но запускается на старой кодовой базе (app-v1.zip), до app-v2.zip распаковывается в /var/app/current, поэтому моя миграция не применяется.

Если я затем запустить другой eb deploy, она будет создавать app-v3.zip, но будет работать migrate на код в app-v2.zip. Таким образом, это работает, но это означает, что я должен запускать eb deploy дважды в любое время, когда хочу изменить либо модели данных, либо статические файлы (эта же проблема относится к collectstatic).

Существует более объяснение и обходной путь on this blog post и this SO question, но все «развернуть Django ЕВ» учебники делать вещи так, как я сделал это с container_commands.

Каков правильный путь?

Answer 1

Вы заставили меня беспокоиться, но я подтвердил, что eb deploy выполняет команды с новой версией кода. Он делает это на промежуточной области, прежде чем фактически освободится на сервере, но это делает с соответствующей версией.

После развертывания вы можете сделать eb logs -a и найти eb-activity.log, чтобы увидеть, как все команды выполняются, и происходит надлежащая миграция.

Что касается потока, я предпочитаю НЕ собирать коллекцию как часть потока EB, так как я высвобождаю этот код непосредственно в S3 (и CloudFront), используя поток на основе gulp. Таким образом, я просто запустить миграцию как часть развертывания (плюс другие вещи частности, к моему заявлению):

01_migrate: 
    command: "django-admin.py migrate --noinput" 
    leader_only: true 

и все работает, как ожидалось.