Question

我正在使用亚马逊的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命令，但没有得到任何其他调试消息。

任何解决方案？提前谢谢。

Answer 1

AWS在使用糟糕的日志记录机制进行故障排除方面不具备开发人员的友好性。

作为最近为Django项目评估EBS的狂热AWS用户，出于同样的原因，我完全赞同这一点。我最终和Heroku一起去了这个原因并且我不会进入，但我认为以下模式有助于这两种方式。

准备您的生产环境的步骤可以进入不同的地方;它们不必在目标Web服务器环境中发生。

我最终将我的make / migrate任务从我的部署自动化中拉出来，转移到之前发生的任务中。我的目标Web服务器环境中发生的唯一事情与该服务器上的代码直接相关。

换句话说：我建议如果你有一个用于构建/测试的CI工具，你可以将你的make / migrate和任何其他准备工作带到你的部署管道中。类似的东西：

结帐代码
运行测试（包括在临时数据库上进行make / migrate以在可能的情况下进行测试）
将应用程序置于维护模式（或类似，如果需要）
快照数据库
制作/迁移制作
部署
如果部署失败，请回滚数据库，回滚应用程序。

然后，您将分离应用服务器的自动化问题和其他产品环境的自动化问题，并让CI处理该问题。你可以在同一个地方处理它们，但很明显它使用EBS的设施有点笨拙。

Answer 2

我的迁移被终止了，因为 Dockerrun.aws.json 文件中保留的内存太低。文档中提供的示例给出了“ 128”作为样本值，而我只是使用了该值。增大“内存” 的值可以解决该问题。

例如 Dockerrun.aws.json 摘录：

  "containerDefinitions": [
    {
      "name": "php-app",
      "image": "php:fpm",
      "essential": true,
      "memory": 512,
      // ... etc. ...
    }
  ]

Django在Amazon Elastic Beanstalk上的迁移命令被终止

2 个答案: