Django 在 Amazon Elastic Beanstalk 上的迁移命令被杀死答案

【问题标题】：Django's migrate command on Amazon Elastic Beanstalk is killedDjango 在 Amazon Elastic Beanstalk 上的迁移命令被杀死
【发布时间】：2015-09-20 01:29:14
【问题描述】：

我正在使用 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 上，相同的容器命令运行良好，没有任何问题。我尝试使用带有 migrate 命令的--verbose 3，但没有收到任何其他调试消息。

有什么解决办法吗？提前致谢。

【问题讨论】：

两个想法：您是否在cfn-init.log 中获得更多信息，您是否考虑过更改您的command timeots？
是的，我的超时时间已经是 1000 秒。它看起来不像超时错误。我从 /var/log/cfn-init-cmd.log 检查了错误，它显示了相同的错误。没有可用的详细调试日志。
如果您没有从 EBS 获得错误或其他有用的诊断信息，可能是其他原因造成的？您是否考虑过它可能是操作系统 - 例如你是OOM killer的受害者吗？
好的。我的迁移存在一些问题，我通过 ssh 手动修复了它。但在那之后我结束了这个问题。 stackoverflow.com/questions/31262031/…
所以我的观点是，当涉及到日志机制不佳的故障排除时，AWS 对开发人员并不友好。或者，如果有一个日志文件记录 ExternalInvocationError 命令错误，则不会在任何地方记录。

标签： python django amazon-web-services amazon-elastic-beanstalk database-migration

【解决方案1】：

我的迁移被终止，因为 Dockerrun.aws.json 文件中保留的内存太低。文档中提供的示例给出了“128”作为示例值，我刚刚使用了它。增加 "memory" 的值可以解决问题。

例如Dockerrun.aws.json 摘录：

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

【讨论】：

我也受到了打击。通常在测试时我们使用小型或微型实例，但它们不足以运行迁移脚本。同样适用于运行 node.js 应用程序。因此建议使用中等实例来查看问题是否得到解决。

【解决方案2】：

在使用糟糕的日志记录机制进行故障排除时，AWS 对开发人员不友好。

作为最近为 Django 项目评估 EBS 的狂热 AWS 用户，出于同样的原因，我完全同意这一点。出于这个原因，我最终选择了 Heroku，但我认为以下模式对这两种方式都有帮助。

准备产品环境的步骤可以在不同的地方进行；它们不必发生在您的目标网络服务器环境中。

我最终将我的制作/迁移任务从我的部署自动化中提取出来，并放到了之前发生的任务中。在我的目标 Web 服务器环境中发生的唯一事情与该服务器上的代码直接相关。

换句话说：如果您有用于构建/测试的 CI 工具，我建议您将您的 make/migrate 和任何其他准备工作拉到您的网络服务器之外的环境中到您的部署管道中。比如：

结帐代码
运行测试（包括在临时数据库上制作/迁移以进行测试）
将应用程序置于维护模式（或类似，如果需要）
快照数据库
在生产环境中制作/迁移
部署
如果部署失败，回滚数据库，回滚应用程序。

然后，您将应用服务器的自动化问题和生产环境其余部分的自动化问题分开，并让 CI 处理这些问题。您可以在同一个地方处理它们，但使用 EBS 的设施显然有点笨拙。

【讨论】：