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

我正在向EB部署一个Django应用程序 - 我的第一个EB部署 - 并且我对事物的顺序感到困惑。在Elastic Beanstalk上进行部署之后运行manage.py命令的正确方法？

我的容器命令有这些：

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，但将在app-v2.zip的代码上运行migrate。所以，它可以工作，但这意味着我需要每次运行eb deploy两次以更改数据模型或静态文件（同样的问题适用于collectstatic）。

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

什么是正确的方法？

来源

2016-02-26 awidgery

确定吗？我一直在使用EB一年，我从来没有见过你描述的行为。博客讨论了这些命令在部署之前在临时区域运行的事实，但临时区域应该有您的新存档。你能否提供更多关于你如何看待这种情况的细节？ – dkarchmer

你让我担心，但我已确认eb deploy确实使用新版本的代码运行命令。在实际发布到服务器之前，它会在临时区域执行此操作，但它会使用正确的版本。

部署完成后可以执行eb logs -a并查找eb-activity.log以查看所有命令如何执行以及是否发生了适当的迁移。

至于流程，我更喜欢不把集合汇编作为EB流程的一部分，因为我使用基于流量的流程将代码直接发布到S3（和CloudFront）中。所以，我只需运行迁移作为部署（加上其他的东西特别是我的应用程序）的一部分：

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

，一切都按预期工作。

来源

2016-02-29 23:29:01 dkarchmer

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

回答

相关问题