python - Heroku部署使用django和gunicorn : Missing gunicorn_django file or dir

Question

This blog建议将以下内容放入我的 Procfile .

web: python myproject_django/manage.py collectstatic --noinput; bin/gunicorn_django --workers=4 --bind=0.0.0.0:$PORT myproject_django/settings.py

但是在 Heroku 上运行我的项目失败了。这是来自 $ Heroku logs :

app[web.1]: bash: bin/gunicorn_django: No such file or directory

所以有一个gunicorn_django文件/目录丢失。该文件/目录应该包含什么以及我应该把它放在哪里？

树

.
├── Procfile
├── myproject_django
│   ├── admin
│   ├── core
│   ├── __init__.py
│   ├── manage.py
│   ├── project_static
│   ├── settings.py
│   ├── templates
│   ├── urls.py
└── requirements.txt

编辑

当我更改我的 Procfile 时至 web: python myproject_django/manage.py run_gunicorn -b 0.0.0.0:$PORT -w 3我的项目运行良好(也提供静态文件)。

然后当我推送到 heroku 并执行 heroku run python myproject_django/manage.py collectstatic 时然后 heroku open ，然后我的网站正在提供服务，但静态文件除外。

树(注意 staticfiles 目录是空的)

.
├── Procfile
├── myproject_django
│   ├── admin
│   ├── core
│   │   ├── admin.py
│   │   ├── __init__.py
│   │   ├── models.py
│   │   ├── static
│   │   │   ├── css
│   │   │   │   ├── base.css
│   │   │   │   ├── layout.css
│   │   │   └── media
|   |   |       ├── pek.ico
|   │   │       ├── pek.png
|   │   │       ├── pek_symbol.png
│   │   ├── tests.py
│   │   ├── views.py
│   ├── __init__.py
│   ├── manage.py
│   ├── settings.py
│   ├── staticfiles
│   ├── templates
│   │   └── core
│   │       ├── 404.html
│   │       ├── 500.html
│   │       ├── home.html
│   │       └── install.html
│   ├── urls.py
└── requirements.txt

在 settings.py 中

PROJECT_PATH = os.path.dirname(os.path.abspath(__file__))
MEDIA_ROOT = os.path.join(PROJECT_PATH, 'static/media')
STATIC_ROOT = os.path.join(PROJECT_PATH,'staticfiles')
STATICFILES_DIRS = (
    os.path.join(PROJECT_PATH, 'core/static'),
)

Edit2(致 Maxime R.)

从第一次编辑的设置开始，我运行了 python myproject_django/manage.py collectstatic ，然后推送到 heroku。 heroku open仍然不提供静态文件。 在 DEBUG=True 时单击图像返回 404 错误:request url: http://myproject_django.herokuapp.com/static/media/pyk1.png .

Edit3(致 Maxime R.)

heroku 日志

2012-08-18T10:18:37+00:00 heroku[web.1]: State changed from up to starting
2012-08-18T10:18:37+00:00 heroku[slugc]: Slug compilation finished
2012-08-18T10:18:38+00:00 heroku[web.1]: Starting process with command `python myproject_django/manage.py run_gunicorn -b 0.0.0.0:47262 -w 3`
2012-08-18T10:18:39+00:00 app[web.1]: /app/myproject_django
2012-08-18T10:18:39+00:00 app[web.1]: STATIC_ROOT: /app/myproject_django/staticfiles
2012-08-18T10:18:39+00:00 app[web.1]: STATICFILES_DIRS: '/app/myproject_django/core/static'
2012-08-18T10:18:39+00:00 app[web.1]: STATIC_ROOT: /app/myproject_django/staticfiles
2012-08-18T10:18:39+00:00 app[web.1]: STATICFILES_DIRS: '/app/myproject_django/core/static'
2012-08-18T10:18:39+00:00 app[web.1]: /app/myproject_django
2012-08-18T10:18:39+00:00 app[web.1]: 2012-08-18 05:18:39 [2] [INFO] Starting gunicorn 0.14.6
2012-08-18T10:18:39+00:00 app[web.1]: 2012-08-18 05:18:39 [2] [INFO] Listening at: http://0.0.0.0:47262 (2)
2012-08-18T10:18:39+00:00 app[web.1]: 2012-08-18 05:18:39 [2] [INFO] Using worker: sync
2012-08-18T10:18:39+00:00 app[web.1]: 2012-08-18 05:18:39 [5] [INFO] Booting worker with pid: 5
2012-08-18T10:18:39+00:00 app[web.1]: 2012-08-18 05:18:39 [6] [INFO] Booting worker with pid: 6
2012-08-18T10:18:39+00:00 app[web.1]: 2012-08-18 05:18:39 [7] [INFO] Booting worker with pid: 7
2012-08-18T10:18:39+00:00 app[web.1]: /app/myproject_django/app/myproject_django
2012-08-18T10:18:39+00:00 app[web.1]: /app/myproject_django
2012-08-18T10:18:39+00:00 app[web.1]: STATICFILES_DIRS: '/app/myproject_django/core/static'
2012-08-18T10:18:39+00:00 app[web.1]: STATIC_ROOT: /app/myproject_django/staticfilesSTATIC_ROOT: /app/myproject_django/staticfiles
2012-08-18T10:18:39+00:00 app[web.1]: STATICFILES_DIRS: '/app/myproject_django/core/static'
2012-08-18T10:18:39+00:00 app[web.1]: 
2012-08-18T10:18:39+00:00 app[web.1]: 
2012-08-18T10:18:39+00:00 app[web.1]: STATICFILES_DIRS: '/app/myproject_django/core/static'
2012-08-18T10:18:39+00:00 app[web.1]: STATIC_ROOT: /app/myproject_django/staticfiles
2012-08-18T10:18:40+00:00 heroku[web.1]: Stopping all processes with SIGTERM
2012-08-18T10:18:40+00:00 heroku[web.1]: State changed from starting to up
2012-08-18T10:18:41+00:00 app[web.1]: 2012-08-18 05:18:41 [7] [INFO] Worker exiting (pid: 7)
2012-08-18T10:18:41+00:00 app[web.1]: 2012-08-18 05:18:41 [2] [INFO] Handling signal: term
2012-08-18T10:18:41+00:00 app[web.1]: 2012-08-18 05:18:41 [6] [INFO] Worker exiting (pid: 6)
2012-08-18T10:18:41+00:00 app[web.1]: 2012-08-18 05:18:41 [5] [INFO] Worker exiting (pid: 5)
2012-08-18T10:18:41+00:00 app[web.1]: 2012-08-18 05:18:41 [2] [INFO] Shutting down: Master
2012-08-18T10:18:42+00:00 heroku[web.1]: Process exited with status 0
2012-08-18T10:18:43+00:00 heroku[router]: GET myproject.herokuapp.com/ dyno=web.1 queue=0 wait=0ms service=36ms status=200 bytes=5474
2012-08-18T10:18:43+00:00 heroku[router]: GET myproject.herokuapp.com/static/media/pek.png dyno=web.1 queue=0 wait=0ms service=16ms status=404 bytes=2613

Answer 1

您提到的博文可以追溯到 2011 年 11 月，当时 virtualenv 安装在 /app 中。 new style virtualenv commit 将虚拟环境从 /app 移到了 /app/.heroku/venv。

这解释了你最初的错误，/app/.heroku/venv/bin/gunicorn_django 应该存在。

这是不好的做法:

通过在推送后收集静态文件，您将无法成功持久地收集静态文件。阅读文档，尤其是 ephemeral filesystem part : collectstatic 和 open 在两个不同的测功机中运行，第一个测功机收集的内容对第二个测功机不可用，因此解释了您在编辑中指出的不一致之处。

它只有在您收集文件并在相同的[web]进程中启动服务器时才有效，但是每次重新启动dyno时它都会重新收集所有静态文件。感觉就像糟糕的设计。

或者:

• 在推送到 heroku 之前收集静态文件
• 使用其他解决方案(如 S3，即使博客文章的目的不是使用它)

无论如何，以优雅高效的工作流程提供静态 Assets 并不容易。

恕我直言，最好在 Procfile 中坚持每个进程一个命令，如果您想链接命令，我建议您开始编写部署脚本。