Команда Django migrate на Amazon Elastic Beanstalk убита

Я использую Amazon Elastic Beanstalk и Django 1.8.2. Вот мои команды контейнера,

container_commands:
  01_wsgipass:
    command: 'echo "WSGIPassAuthorization On" >> ../wsgi.conf'
  02_makemigrations:
    command: "source /opt/python/run/venv/bin/activate && python manage.py makemigrations --merge --noinput"
    leader_only: true
  03_migrate:
    command: "source /opt/python/run/venv/bin/activate && python manage.py migrate --noinput"
    leader_only: true

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

Synchronizing apps without migrations:
  Creating tables...
  Running deferred SQL...
  Installing custom SQL...
  Running migrations:
  Rendering model states.../bin/sh: line 1: 21228 Killed                  python manage.py migrate --noinput
   (ElasticBeanstalk::ExternalInvocationError)

Примечание. Те же команды контейнера работали нормально без каких-либо проблем ранее в Elastic Beanstalk. Я пробовал использовать --verbose 3 с помощью команды migrate, но не получил других отладочных сообщений.

Какие-нибудь решения? Заранее спасибо.


python django amazon-web-services amazon-elastic-beanstalk database-migration
person Babu    schedule 02.07.2015    source источник
comment
Две мысли: есть ли у вас дополнительная информация в cfn-init.log и смотрели ли вы на изменение командных временных интервалов < / а>?   -  person Peter Brittain    schedule 06.07.2015
comment
Да, у меня таймаут уже 1000 секунд. Это не похоже на ошибку тайм-аута. Я проверил ошибку в /var/log/cfn-init-cmd.log, там та же ошибка. Нет подробных журналов отладки.   -  person Babu    schedule 06.07.2015
comment
Если вы не получаете ошибок или другой полезной диагностики от EBS, может быть, это делает что-то еще? Вы думали, что это может быть ОС - например, Вы стали жертвой убийцы OOM?   -  person Peter Brittain    schedule 08.07.2015
comment
Хорошо. Были некоторые проблемы с моими миграциями, и я исправил их вручную с помощью ssh. Но после этого у меня возникла эта проблема. stackoverflow.com/questions/31262031/   -  person Babu    schedule 08.07.2015
comment
Итак, я хочу сказать, что AWS не удобен для разработчиков, когда дело доходит до устранения неполадок с плохим механизмом ведения журнала. Или, если существует один файл журнала для регистрации ошибок команды ExternalInvocationError, он нигде не документируется.   -  person Babu    schedule 08.07.2015
comment
@Babu проверьте состояние вашей базы данных. Скорее всего есть какая-то блокировка, возможно, таблица базы данных заблокирована. Попробуйте перезапустить сервер базы данных.   -  person Aamir Adnan    schedule 08.07.2015
comment
@Babu Поскольку все работает нормально на локальной машине, вероятность того, что у EBS возникнут проблемы, очень маловероятна. Поэтому я думаю, как предлагает Питер Бриттен, проверяйте использование вашей оперативной памяти при выполнении этих команд (может быть, это делает OOM Killer). В качестве быстрого решения увеличьте оперативную память вашего экземпляра и перезапустите процесс.   -  person Haridas N    schedule 10.07.2015

Ответы (2)


arrow_upward
7
arrow_downward

AWS не очень удобен для разработчиков, когда дело доходит до устранения неполадок с плохим механизмом ведения журнала.

Как заядлый пользователь AWS, недавно оценивший EBS для проекта Django, я полностью согласен с этим по тем же причинам. В конечном итоге я перешел на Heroku по этой и причинам, которые я не буду вдаваться в подробности, но я думаю, что следующий шаблон поможет в любом случае.

Шаги по подготовке вашей производственной среды могут выполняться в разных местах; они не обязательно должны происходить в вашей целевой среде веб-сервера.

В итоге я вытащил задачи создания / переноса из системы автоматизации развертывания в задачи, которые выполнялись непосредственно перед этим. Единственное, что происходит в моей целевой среде веб-сервера, напрямую связано с кодом на этом сервере.

Другими словами: я рекомендую, если у вас есть инструмент CI для сборки / тестирования, вы перетаскиваете свой make / migrate и любые другие подготовительные операции в среду за пределами вашего веб-сервера в конвейер развертывания. Что-то вроде:

  • Код оформления заказа
  • Выполнить тесты (включая make / migrate в эфемерной базе данных для проверки, если это возможно)
  • Перевести приложение в режим обслуживания (или аналогичный, если требуется)
  • База данных моментальных снимков
  • Сделать / перейти на производство
  • Развертывать
  • Если развертывание не удалось, откатить БД, откатить приложение.

Затем вы разделяете проблемы автоматизации для вашего сервера приложений и автоматизации для остальной части вашей производственной среды и позволяете вашему CI справиться с этим. Вы можете обрабатывать их в одном и том же месте, но, очевидно, сделать это с помощью средств EBS несколько неудобно.

person alph486    schedule 08.07.2015

arrow_upward
2
arrow_downward

Мои миграции были прерваны из-за слишком низкого объема памяти, зарезервированной в файле Dockerrun.aws.json. Пример, представленный в документации, дал «128» как примерное значение, и я только что использовал это. Увеличение значения «памяти» решило проблему.

например Dockerrun.aws.json отрывок:

  "containerDefinitions": [
    {
      "name": "php-app",
      "image": "php:fpm",
      "essential": true,
      "memory": 512,
      // ... etc. ...
    }
  ]
person kaapstorm    schedule 20.12.2018
comment
Меня тоже это поразило. Обычно при тестировании мы используем маленькие или микро-экземпляры, но их недостаточно для запуска скриптов миграции. То же самое применимо для запуска приложений node.js. Поэтому рекомендуется использовать средние экземпляры, чтобы увидеть, решается ли проблема. - person Babu; 20.12.2018