1 Востаннє редагувалося ping (05.05.2014 10:17:19)

Тема: Django application на сервері - є питання

Доброго дня.
Запускаю Cartridge (Mezzanine + ecart) на сервері (debian+nginx+uwsgi)
В режимі внутрішнього веб-сервера (manage.py runserver) все працює нормально.
При передачі на uwsgi або gunicorn - не відображаються файли в static/media/
Спершу не хотіли взагалі завантужуватися static/, але це вдалося побороти.

чесно кажучи, вже голова не варить - де копати.

причому інша CMS на основі Django - Feincms - нормально працює без танців з бубном

p.s.
наскільки логічніше та простіше це все вирішується на іншому python-фреймворку -  web2py - словами не передати.

First, solve the problem. Then, write the code. (c)JJ

2 Востаннє редагувалося Singularity (05.05.2014 11:10:02)

Re: Django application на сервері - є питання

Дай конфіг nginx і подивись логи в /var/log/nginx/

3 Востаннє редагувалося ping (05.05.2014 12:20:52)

Re: Django application на сервері - є питання

Singularity написав:

Дай конфіг nginx і подивись логи в /var/log/nginx/

nginx для даної аплікації прокидає напряму, а не віддає статику самостійно:

server {
        listen          68.688.688.688:80;
        server_name     my_server_name;

        access_log /var/log/nginx/app-cartridge-access.log;
        error_log /var/log/nginx/app-cartridge-error.log;

        location / {
            uwsgi_pass      unix:///tmp/my_app.sock;
            include         uwsgi_params;
            uwsgi_param     UWSGI_SCHEME $scheme;
            uwsgi_param     SERVER_SOFTWARE    nginx/$nginx_version;
        }
}

gunicorn запускаю взагалі напряму:

gunicorn my_project.wsgi -b 68.688.688.688:8000

так що справа не в nginx

щойно зробив і запустив ТОТОЖНУ копію на локальному компі - працює, зараза.

і там і там однакові django версії 

pip freeze | grep Django
Django==1.6.4

п.с.
хіба звіряти всі елементи поштучно...

p.p.s.
debug видає однаковий на обох варіантах:

2014-05-05 12:08:52 [1214] [DEBUG] GET /gallery/
2014-05-05 12:08:52 [1214] [DEBUG] GET /static/media/uploads/galleries/12.jpg
2014-05-05 12:08:52 [1214] [DEBUG] GET /static/media/uploads/galleries/10.jpg
2014-05-05 12:09:28 [1214] [DEBUG] GET /gallery/
2014-05-05 12:09:28 [1214] [DEBUG] GET /static/css/bootstrap.css
2014-05-05 12:09:28 [1214] [DEBUG] GET /static/css/mezzanine.css
2014-05-05 12:09:28 [1214] [DEBUG] GET /static/css/bootstrap-theme.css
2014-05-05 12:09:28 [1214] [DEBUG] GET /static/css/cartridge.css
2014-05-05 12:09:28 [1214] [DEBUG] GET /static/mezzanine/css/magnific-popup.css
2014-05-05 12:09:28 [1214] [DEBUG] GET /static/mezzanine/js/jquery-1.7.1.min.js
2014-05-05 12:09:28 [1214] [DEBUG] GET /static/js/bootstrap.js
2014-05-05 12:09:29 [1214] [DEBUG] GET /static/js/bootstrap-extras.js
2014-05-05 12:09:29 [1214] [DEBUG] GET /static/mezzanine/js/magnific-popup.js
2014-05-05 12:09:29 [1214] [DEBUG] GET /static/media/uploads/galleries/12.jpg
2014-05-05 12:09:29 [1214] [DEBUG] GET /static/media/uploads/galleries/10.jpg
2014-05-05 12:09:29 [1214] [DEBUG] GET /static/fonts/glyphicons-halflings-regular.woff

от тільки файли в media не відображаються

Page not found (404)
Request Method:    GET
Request URL:    http://68.688.688.688:8585/static/media/uploads/galleries/12.jpg
'media/uploads/galleries/12.jpg' could not be found
You're seeing this error because you have DEBUG = True in your Django settings file. Change that to False, and Django will display a standard 404 page.

фізично файли є і з правами доступу проблем нема:

$ ls -l static/media/uploads/galleries/*
-rw-r--r-- 1 www-data www-data 66407 May  4 21:28 static/media/uploads/galleries/10.jpg
-rw-r--r-- 1 www-data www-data 78534 May  4 21:29 static/media/uploads/galleries/12.jpg
First, solve the problem. Then, write the code. (c)JJ

4 Востаннє редагувалося Singularity (05.05.2014 12:34:50)

Re: Django application на сервері - є питання

ну він і не знаю про статику
додай біля location

    location /static/ {
        root /path/project;
        expires 1y;
    }    
    location /media/ {
        root /path/project;
        expires 1y;
    }

тільки у мене чомусь nginx сам додає до шляху на диску static.
ну тобто статика повинна бути  при /path/project в  /path/project/static

5 Востаннє редагувалося ping (05.05.2014 12:52:23)

Re: Django application на сервері - є питання

зупинив nginx
запустив вручну gunicorn:

sudo -u www-data -g www-data gunicorn my_project.wsgi --bind 68.688.688.688:8585 --log-level  debug

дивлюся конкретний файл :

http://68.688.688.688:8585/static/media/uploads/galleries/10.jpg

отримую:

Page not found (404)
Request Method:    GET
Request URL:    http://68.688.688.688:8585/static/media/uploads/galleries/10.jpg
'media/uploads/galleries/10.jpg' could not be found
You're seeing this error because you have DEBUG = True in your Django settings file. Change that to False, and Django will display a standard 404 page.

лог веб-сервера пише:

2014-05-05 12:47:58 [7318] [INFO] Starting gunicorn 18.0
2014-05-05 12:47:58 [7318] [DEBUG] Arbiter booted
2014-05-05 12:47:58 [7318] [INFO] Listening at: http://68.688.688.688:8585 (7318)
2014-05-05 12:47:58 [7318] [INFO] Using worker: sync
2014-05-05 12:47:58 [7323] [INFO] Booting worker with pid: 7323
2014-05-05 12:48:30 [7323] [DEBUG] GET /static/media/uploads/galleries/10.jpg

тобто - тут уже веб-сервер ( нічого не обробляючи?)  має віддати картинку.

First, solve the problem. Then, write the code. (c)JJ

6 Востаннє редагувалося miroslav.chandler (05.05.2014 16:02:24)

Re: Django application на сервері - є питання

ping написав:

зупинив nginx
запустив вручну gunicorn:

sudo -u www-data -g www-data gunicorn my_project.wsgi --bind 68.688.688.688:8585 --log-level  debug

дивлюся конкретний файл :

http://68.688.688.688:8585/static/media/uploads/galleries/10.jpg

отримую:

Page not found (404)
Request Method:    GET
Request URL:    http://68.688.688.688:8585/static/media/uploads/galleries/10.jpg
'media/uploads/galleries/10.jpg' could not be found
You're seeing this error because you have DEBUG = True in your Django settings file. Change that to False, and Django will display a standard 404 page.

лог веб-сервера пише:

2014-05-05 12:47:58 [7318] [INFO] Starting gunicorn 18.0
2014-05-05 12:47:58 [7318] [DEBUG] Arbiter booted
2014-05-05 12:47:58 [7318] [INFO] Listening at: http://68.688.688.688:8585 (7318)
2014-05-05 12:47:58 [7318] [INFO] Using worker: sync
2014-05-05 12:47:58 [7323] [INFO] Booting worker with pid: 7323
2014-05-05 12:48:30 [7323] [DEBUG] GET /static/media/uploads/galleries/10.jpg

тобто - тут уже веб-сервер ( нічого не обробляючи?)  має віддати картинку.


ну так ж gunicorn вам каже, шо він пробує резолвити цей запит. пропишіть правильно конфіги нгінкса на статику. при правильному конфігу, запит статики на gunicorn іти не має

pew pew :D
Блоґ

7

Re: Django application на сервері - є питання

ну так ж gunicorn вам каже, шо він пробує резолвити цей запит. пропишіть правильно конфіги нгінкса на статику. при правильному конфігу, запит статики на gunicorn іти не має

nginx відключено(ви , мабуть, пропустили цю фразу - "зупинив nginx"), gunicorn дивиться напряму --bind 68.688.688.688:8585

nginx працює в парі з uwsgi

а gunicorn - може працювати одразу на прийом http-запитів самостійно. от я на ньому і пробую.

First, solve the problem. Then, write the code. (c)JJ

8

Re: Django application на сервері - є питання

ping написав:

ну так ж gunicorn вам каже, шо він пробує резолвити цей запит. пропишіть правильно конфіги нгінкса на статику. при правильному конфігу, запит статики на gunicorn іти не має

nginx відключено(ви , мабуть, пропустили цю фразу - "зупинив nginx"), gunicorn дивиться напряму --bind 68.688.688.688:8585

nginx працює в парі з uwsgi

а gunicorn - може працювати одразу на прийом http-запитів самостійно. от я на ньому і пробую.

таки пропустив, але нашо?
на скільки я знаю, gunicorn взагалі не вміє резолвити статику.
статика може віддаватися тільки на вбудованому сервері (manage.py runserver) і до в дебаг режимі.
так шо налаштуйте нормально нгінкс і буде вам щастя)

pew pew :D
Блоґ

9

Re: Django application на сервері - є питання

і з чого ви взагалі взяли, шо спарва не в нгінкс?
у вас ні рута нема прописаного ні локейшенів. звідки нгінксу статику брати то?

pew pew :D
Блоґ

10 Востаннє редагувалося ping (05.05.2014 20:09:56)

Re: Django application на сервері - є питання

miroslav.chandler написав:
ping написав:

ну так ж gunicorn вам каже, шо він пробує резолвити цей запит. пропишіть правильно конфіги нгінкса на статику. при правильному конфігу, запит статики на gunicorn іти не має

nginx відключено(ви , мабуть, пропустили цю фразу - "зупинив nginx"), gunicorn дивиться напряму --bind 68.688.688.688:8585

nginx працює в парі з uwsgi

а gunicorn - може працювати одразу на прийом http-запитів самостійно. от я на ньому і пробую.

таки пропустив, але нашо?

для чистоти екперименту. щоб виключити ланку з підозрінь.

на скільки я знаю, gunicorn взагалі не вміє резолвити статику.

чого це раптом? може. я ж зкопіював через git цей самий (включаючи ВСІ налаштування) проект на локальну машину. і на локалці ця сама команда чудово запускає проект під gunicorn разом з статикою.
просто його радять ставити за проксі-сервером для пришвидшення і т.п.

Deploying Gunicorn
We strongly recommend to use Gunicorn behind a proxy server.

Although there are many HTTP proxies available, we strongly advise that you use Nginx. If you choose another proxy server you need to make sure that it buffers slow clients when you use default Gunicorn workers. Without this buffering Gunicorn will be easily susceptible to denial-of-service attacks. You can use slowloris to check if your proxy is behaving properly.


статика може віддаватися тільки на вбудованому сервері (manage.py runserver) і до в дебаг режимі.

запевняю Вас, що помиляєтеся.
статику віддає багато веб-серверів.

standalone?
GUNICORN:
Not usually recommended. Use behind another webserver to avoid problem with slow clients

DJANGO-CPSERVER:
Yes, for low-medium volume sites. But often used behind other servers. Based on CherryPy's webserver

DJANGO WSGISERVER:
Yes, for low-medium volume sites. But often used behind other servers. Based on CherryPy's webserver. A fork of django-cpserver

https://www.djangopackages.com/grids/g/webserver/

так шо налаштуйте нормально нгінкс і буде вам щастя)

обов’язково налаштую. тому що на VPS у мене UWSGI в якості робочого коника , а от він уже не може без  проксі-сервера.
але зараз - питання не в ньому.
якщо зараз пущу через nginx - так і не дізнаюся - в чому проблема.

єдина відмінність між компами - на сервері debian-64, на локалці - debian-32
ну і різні пакети встановлено, хоч версія пітона однакова - 2.7

First, solve the problem. Then, write the code. (c)JJ

11

Re: Django application на сервері - є питання

miroslav.chandler написав:

і з чого ви взагалі взяли, шо спарва не в нгінкс?
у вас ні рута нема прописаного ні локейшенів. звідки нгінксу статику брати то?

ось аналог для тестування feincms (теж з породи Django):

server {
        listen          68.688.688.688:80;
        server_name     any-server.com;

        access_log /var/log/nginx/as-access.log;
        error_log /var/log/nginx/as-error.log;



        #to enable correct use of response.static_version
###        location ~* /(\w+)/static(?:/_[\d]+.[\d]+.[\d]+)?/(.*)$ {
        #    expires max;
###        }
###        location ~* /(\w+)/static/ {
###            root /home/xxxxxxxx/py/xxx/xxxxxx/;
###            #remove next comment on production
###            expires max;
###        }
        location / {
#            uwsgi_pass      127.0.0.1:9090;
            uwsgi_pass      unix:///tmp/wig.sock;
            include         uwsgi_params;
            uwsgi_param     UWSGI_SCHEME $scheme;
            uwsgi_param     SERVER_SOFTWARE    nginx/$nginx_version;
        }
}

все нормально працює в спарці uwsgi+nginx на тому ж сервері. і uwsgi прекрасно видає статику і картинки.

First, solve the problem. Then, write the code. (c)JJ

12

Re: Django application на сервері - є питання

які заголовки в статики на локалці?

pew pew :D
Блоґ

13

Re: Django application на сервері - є питання

miroslav.chandler написав:

які заголовки в статики на локалці?

прошу пробачити  - не зрозумів питання.

на сервері загнав копію на git 
git push

на локалці - зклонував
git clone https://xxxxxxxxxxxxx

envirovment дещо різняться, бо різні версії ОС (32 та 64 біт)
запускаю однакову команду веб-серверу (хоча - веб-сервери теж можуть різнитися - бо різні ОС)

на локалці - показує картинки, на сервері не показує.

ЯК ЗРОЗУМІТИ ЩО НЕ ТАК?


п.с.
а virtualenv використовувати поки що не хочу.

First, solve the problem. Then, write the code. (c)JJ

14

Re: Django application на сервері - є питання

ping написав:
miroslav.chandler написав:

які заголовки в статики на локалці?

прошу пробачити  - не зрозумів питання.

на сервері загнав копію на git 
git push

на локалці - зклонував
git clone https://xxxxxxxxxxxxx

envirovment дещо різняться, бо різні версії ОС (32 та 64 біт)
запускаю однакову команду веб-серверу (хоча - веб-сервери теж можуть різнитися - бо різні ОС)

на локалці - показує картинки, на сервері не показує.

ЯК ЗРОЗУМІТИ ЩО НЕ ТАК?


п.с.
а virtualenv використовувати поки що не хочу.

подивіться, які заголовки віддає сервер коли ви відкриваєте картинку.

pew pew :D
Блоґ

15

Re: Django application на сервері - є питання

2 miroslav.chandler
швидше всього, проблема в Django.
віддача статики через веб-сервер при продакшн режимі не схвалюється і нормально не підтримується.
тобто, якщо включити опцію STATICFILES_DIRS - працює, але то значить, що шурує по всіх можливих каталогах.
а , після manage.py collectstatic в один каталог, до нього треба йти через STATIC_ROOT , відключивши STATICFILES_DIRS
тоді і починаються трабли.

пустив статику через nginx  і не морочу голову. завтра (чи коли там) вийде нова версія django, то знову заглиблюватися в нюанси налаштування віддачі статики?
навіщо, якщо це при розробці не мішає, а при робочому режимі - не  використовується!

First, solve the problem. Then, write the code. (c)JJ

16

Re: Django application на сервері - є питання

ping написав:

2 miroslav.chandler
швидше всього, проблема в Django.
віддача статики через веб-сервер при продакшн режимі не схвалюється і нормально не підтримується.
тобто, якщо включити опцію STATICFILES_DIRS - працює, але то значить, що шурує по всіх можливих каталогах.
а , після manage.py collectstatic в один каталог, до нього треба йти через STATIC_ROOT , відключивши STATICFILES_DIRS
тоді і починаються трабли.

пустив статику через nginx  і не морочу голову. завтра (чи коли там) вийде нова версія django, то знову заглиблюватися в нюанси налаштування віддачі статики?
навіщо, якщо це при розробці не мішає, а при робочому режимі - не  використовується!

шоб кожен раз не робити collectstattic
можете пускати статику через нгінкс, ніхто вам не забороняє)

pew pew :D
Блоґ