ModuleNotFoundError：部署到 Elastic Beanstalk 时没有名为“django”的模块

Posted 2023-03-04

【中文标题】ModuleNotFoundError：部署到 Elastic Beanstalk 时没有名为“django”的模块

【英文标题】：ModuleNotFoundError: No module named 'django' when deploying to Elastic Beanstalk

【发布时间】：2020-05-09 08:00:05

【问题描述】：

我一直在本地开发一个 Django 项目，我最终决定将它发布到 AWS Elastic Beanstalk，在部署过程中，我不断收到一条错误消息：

从 django.core.wsgi 导入 get_wsgi_application

没有名为“django”的模块

我已经浏览了官方的tutorial from AWS 以及tutorial from the Real Python 我已经通过运行pip freeze 验证了实际上已经安装了Django，并且它返回

...

colorama==0.3.9

Django==2.2.9

django-celery==3.3.1

....

我也一直在本地广泛地使用 Django。但只是为了确保我运行了以下命令并得到了这个输出。

(.venv) $ source .venv/bin/activate

(.venv) $ pip install django

已满足要求：.​​/.venv/lib/python3.7/site-packages (2.2.9) 中的 django

已满足要求：.​​/.venv/lib/python3.7/site-packages 中的 sqlparse（来自 django）（0.3.0）

要求已经满足：./.venv/lib/python3.7/site-packages 中的 pytz（来自 django）（2019.3）

当我跑步时：

(.venv) $ python
Python 3.7.4 (default, Jul  9 2019, 18:13:23) 
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> print(django.__file__)
.../code/core_web_app/.venv/lib/python3.7/site-packages/django/__init__.py

对不起，如果这太过分了，但我看过的大多数帖子都有 cmets 询问是否安装了 Django 或说必须安装 Django。我的假设是 Django 安装在我的本地机器上，但没有安装在我的远程机器上。此外，我已经注意到post 并确保我的 requirements.txt 文件也在我的根目录中。您可以在下面找到一些其他信息。

.ebextensions/django.config

    option_settings:
  "aws:elasticbeanstalk:application:environment":
    DJANGO_SETTINGS_MODULE: "myapp.settings"
    "PYTHONPATH": "/opt/python/current/app/src:$PYTHONPATH"
  "aws:elasticbeanstalk:container:python":
    WSGIPath: src/myapp/wsgi.py
    NumProcesses: 3
    NumThreads: 20
  "aws:elasticbeanstalk:container:python:staticfiles":
    "/static/": "www/static/"

src/myapp/wsgi.py

import os

from django.core.wsgi import get_wsgi_application

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myapp.settings')

application = get_wsgi_application()

任何帮助将不胜感激，因为这是我第一次使用这个，我想我在某个地方犯了一个非常愚蠢的错误。

【问题讨论】：

我认为你应该在某个地方定义虚拟环境路径，就像在 linux 中我们有配置 .ini 文件，我们在其中定义虚拟环境路径。

我在这里的第一个想法是某些东西，也许是 requirements.txt，没有提交。有好几次我忘记在运行eb deploy 之前提交文件，这导致了问题。说到这里，这是如何部署的？

【参考方案1】：

为了回答您的问题，在使用 AWS ElasticBeanstalk(EBS) 部署 Django 或 flask 或 dash 应用程序时，您需要检查的事项很少。

注意：如果应用程序使用 AWS EBSCLI（即 EBS 的命令行功能，而不是通过您的 AWS 账户上的 EBS 的用户界面进行托管的方法）托管，则概述了以下步骤。 根据我的个人经验，我发现托管应用程序的 UI 方法不适用于烧瓶、Django 或 dash 应用程序。

在将应用程序托管到 EBS 时，检查托管日志是否有任何错误。即使 EBS 提示您已成功托管应用程序，您也必须交叉检查日志以查找任何错误。 确认步骤 1 中没有错误后，导航到 EBS 应用程序的日志控制台，下载整个日志，然后检查是否有任何其他错误。如果您有任何错误，您必须先纠正它们。 既然您说 AWS Linux 机器无法导入 Django 包，可能是您在不同的虚拟环境下手动检查 Django 包，而 AWS EBS 已在另一个虚拟环境下托管您的应用程序环境。 为了解决第 3 步，碰巧任何使用 AWS EBS 在 linux 服务器上托管的应用程序都托管在以下虚拟环境路径下。 /opt/python/run/venv/bin。为了验证这一点，只需在连接到您的 linux 服务器后键入命令cd /opt/python/run/venv/bin。一旦您能够导航到此路径，请尝试通过提供 source ./activate 来激活 virtualenv 激活 AWS EBS 为您的应用程序创建的 virtualenv 后，尝试在此 virtualenv 中启动 python，然后尝试 import django。如果你发现这个 virtualenv 下没有安装 django 包，你必须手动安装它，因为这是你的托管应用程序将引用的 virtualenv。并且您的托管应用程序需要引用的任何新包都必须安装在这个 virtualenv 下。 为了进一步向您提供更多信息，您的托管应用程序将驻留在此目录/opt/python/bundle/2/app 下的 AWS linux 服务器上。如果您将来愿意更改应用程序代码或任何支持文件，可以参考此目录。例如，如果您想更改任何源代码，您可以直接编辑此存储库下的源代码文件并重新启动服务器以使更改生效。

更新： 由于您指定在托管您的应用程序期间，您收到了关于找不到django包的错误，请按照以下步骤纠正此错误。

在创建requirements.txt 文件时，请确保该文件中仅存在应用程序所需的包。当您执行pip freeze requirements.txt 时，当前环境中存在的所有包都将在requirements.txt 文件中创建一个条目。这可能会在 AWS EBS 尝试安装此文件时产生错误。原因是，例如，PackageA 和 PackageB 可能是 PackageC 的依赖包。如果您安装 PackageC，则会自动安装 PackageA 和 PackageB。话虽如此，您必须删除 requirements.txt 文件中的 PackageA 和 PackageB 并只保留 PackageC。因为 PackageC 的安装会自动安装它的依赖包，即 PackageA 和 PackageB。因此，为了简短起见，您只需将使用 pip install 手动安装的软件包包含在您的本地计算机中的 requirements.txt 文件中。所有其他包将是这些包的依赖包，并在安装主包时自动安装。所以这些依赖包需要从requirements.txt中移除。 如果您仍然收到相同的错误，一旦托管应用程序出现错误，请尝试使用 CLI（命令行界面）连接到您的 AWS Linux 机器，通过执行 cd /opt/python/run/venv/bin 导航到虚拟环境路径，激活它使用source ./activate，调用python 解释器，然后尝试手动导入包。如果您发现任何软件包被卸载，您可以手动安装它们并重新启动服务器以使更改生效。

更多详情可以参考这个link。虽然这是为托管烧瓶应用程序而创建的，但托管 django 应用程序也可以在相同的线路上工作。

【讨论】：

最后两点：1）官方文档从未对pip install django说。我不明白你为什么要经历所有这些解释。 OPs 问题专门针对 Django。尽管如此，aws 文档从不告诉您安装它，并且将其添加到 requirements.txt 没有任何作用——同样的错误。 2）你不应该潜入虚拟环境来手动修复和安装东西。当您切换环境时，这将导致问题。所以说真的，我看不到这里的价值。