在 Elastic Beanstalk 上部署后运行 manage.py 命令的正确方法？答案

【问题标题】：Correct way to run manage.py commands after deployment on Elastic Beanstalk?在 Elastic Beanstalk 上部署后运行 manage.py 命令的正确方法？
【发布时间】：2016-06-10 00:43:07
【问题描述】：

我正在将 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

然而，我注意到的是，每次部署时，这些容器命令都会在我的 old 代码库上运行。假设我当前的代码是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，但会在app-v2.zip 中的代码上运行migrate。所以，它可以工作，但这意味着我必须在任何时候运行eb deploy 两次才能更改数据模型或静态文件（同样的问题适用于collectstatic）。

on this blog post 和 this SO question 有更多解释和解决方法，但所有“将 Django 部署到 EB”教程都按照我使用 container_commands 的方式进行操作。

正确的方法是什么？

【问题讨论】：

你确定吗？我已经使用 EB 一年了，我从未见过你描述的行为。该博客讨论了命令在部署之前在暂存区域运行但该暂存区域应该有您的新存档的事实。您能否详细说明您认为这是如何发生的？

标签： django amazon-web-services deployment amazon-elastic-beanstalk

【解决方案1】：

您让我担心，但我已经确认 eb deploy 确实使用新版本的代码运行命令。它在暂存区执行此操作，然后实际发布到服务器，但它使用正确的版本。

您可以在部署后执行eb logs -a 并查找eb-activity.log 以查看所有命令是如何执行的，以及正确的迁移发生。

对于流程，我不希望将 collectstatics 称为 EB 流程的一部分，因为我使用基于 gulp 的流程将该代码直接发布到 S3（和 CloudFront）中。因此，我只是将 migrate 作为部署的一部分运行（加上我的应用程序特有的其他内容）：

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

一切都按预期进行。

【讨论】：