Dne 20. června 2017 2:25 Jan Walter <[email protected]> napsal(a): > Protože se mi nepovedlo rychle rozběhnout gunicorn (nedával jsem teď pár > let pozor, to je standard i pro produkci?), debuggoval jsem nainstalovaný > balíček, našel podezřelou závislost libxml2, nainstaloval její systémový > balík a následně udělal nový env a pip install, kde se leccos souvisejícího > buildovalo. Moje chápání podstaty a zejm. odlišnosti mezi manage.py a wsgi > je dost na vodě, ale třeba to přes noc docvakne. Kdybyste mi to někdo uměl > jednoduše vysvětlit, budu nadšen stejně, jako že to už funguje :). > > Tak gratuluji :)
"odlišnosti mezi manage.py a wsgi" - tím "wsgi" asi myslíš mod_wsgi. Protože mod_wsgi a WSGI jsou různé věci :) Co dělá manage runserver: spustí django.core.servers.basehttp.WSGIServer , který je odvozený od wsgiref import simple_server ze standardní knihovny Pythonu, a jako handler to tomu dá Django WSGI handler, který umí odpovídat na requesty. Toto vše běží v kontextu toho příkazu manage.py, takže pod venvem, pod kterým to spouštíte. Co dělá gunicorn: gunicorn je web server naimplementovaný v Pythonu, můžete si ho nainstalovat do venvu. Django aplikace se v něm spouští opět přes WSGI handler té Django aplikace. Situace je v podstatě stejná jako při "manage runserver", akorát místo wsgiref.simple_server se použije gunicorn webserver. Ta Django aplikace běží přímo v procesech nebo vláknech spuštěných gunicornem, pokud gunicorn spustíte z venvu, tak i Django aplikace bude používat tenhle venv. Co dělá mod_wsgi: je to modul do Apache webserveru. Apache je napsaný v C a i moduly do něj jsou v C. Python se z něj spouští pomocí Python C API (Python.h): https://github.com/GrahamDumpleton/mod_wsgi/blob/033bfc7ac5bce9bacb9bbc7594f48d7c5551df3a/src/server/wsgi_interp.c#L2263 Takže např. to, jaká verze Pythonu se spustí, záleží na tom, oproti čemu byl mod_wsgi zkompilovaný a s čím je nalinkovaný (libpython). Teoreticky se může stát, že by mohly kolidovat závislosti (C knihovny) Python modulů a Apache (nebo ostatních *_mod v Apache). A jak do toho všeho zapadá venv? venv je jen sada adresářů, která obsahuje Python moduly. Pokud spustíte python "normálně", tj. bez venvu, tak se pro importované moduly použije cesta např. /usr/lib/python3/dist-packages. Když spustíte python ve venvu (např. venv/bin/python), tak se pustí ten Python (binárka), pomocí kterého byl tento venv vytvořen, jen se místo cesty /usr/lib/python3/dist-packages použije venv/lib/python3.5/site-packages. Jak je to s venv a mod_wsgi? Tady může nastat rozpor v tom, pomocí které Python binárky byl ten venv vytvořen, a pomocí čeho (libpython) potom ten kód spouští mod_wsgi - jestli tyhle dvě věci (python binárka a libpython knihovna) jsou spolu kompatibilní, nejlépe jestli oboje pochází ze stejného buildu zdrojových souborů Pythonu. U mod_wsgi je ještě několik dalších věcí, které se mohou rozbít (např. Python subinterpretery), a taky best practice je nespouštět Python věci přímo v procesu Apache, ale spustit na to dedikovaný proces, se kterým ten Apache komunikuje - mod_wsgi Daemon mode (což mimochodem mod_python neumí). No a to už pak člověk nemusí mod_wsgi používat vůbec (a řešit tyhle obskurity), ale pustit Python aplikaci nějak "normálně" (ne z nějakého cizího C kódu) a nechat ji z Apache/Nginxu/čehokoliv volat přes HTTP nebo FastCGI protokol. No a Gunicorn je implementace HTTP v Pythonu. Používá se v produkci od roku 2010. PM > Každopádně dík moc za pomoc, > John > > On Mon, Jun 19, 2017 at 12:20 PM Petr Messner <[email protected]> > wrote: > >> Přinejhorším můžeš kód toho balíku upravit (editovat přímo soubor v envu) >> a dát si tam nějaké debug logování. >> >> A když si to spustíš přes gunicorn místo mod_wsgi, tak to funguje? Kdoví, >> oproti jakému python interpretreu je ten mod_wsgi zkompilovaný. >> >> PM >> >> Dne 19. června 2017 11:02 Jan Walter <[email protected]> napsal(a): >> >>> Díky moc za nápady. >>> >>> Metodu volám s jednoduchým modelovým vstupem totožným v obou případech. >>> Vypsal jsem si v místě volání locals() a globals() (ne do hloubky). >>> Jediný, co vidím jako odlišnost je cesta k importovaným balíčkům >>> /home/ct/www/env/local/lib/python2.7/site-packages/django/db/models/__init__.pyc >>> (apache) vs. >>> /home/ct/www/env/lib/python2.7/site-packages/django/db/models/__init__.pyc >>> (manage.py) >>> nicméně local je jen link >>> lrwxrwxrwx 1 ct ct 20 Jun 18 20:52 /home/ct/www/env/local/lib -> >>> /home/ct/www/env/lib >>> >>> Apache běží pod jiným uživatelem (WSGIDaemonProcess má ale nastaven >>> atribut user), je to asi dobrá hypotéza; i když jsem ale dal celýmu obsahu >>> virtualenvu rwx, je to beze změny. Možná nějaký pracovní soubory, adresáře, >>> rychle jsem prohlídl, jestli to něco čte (bez úspěchu), ještě to budu muset >>> prozkoumat víc. Divný je, že to nepíše žádnou chybu, suverénně to vrátí ''. >>> Je to v principu věc, která z jednoho řetězce udělá jiný bez dalších >>> externalit. >>> >>> Dost možná přehlížím něco úplně triviálního, až to najdu, dám vědět. >>> >>> Ještě jednou díky. >>> >>> >>> On Mon, Jun 19, 2017 at 8:57 AM Vláďa Macek <[email protected]> wrote: >>> >>>> Ahoj, >>>> >>>> to jsou nepříjemný problémy. Mimochodem, jakmile to půjde, opravdu >>>> upgraduj >>>> Django. >>>> >>>> Neznám premailer, ale vypadá to, že nemá nic společného s běhovým >>>> prostředím/middlewary, takže by nemělo na způsobu spuštění záležet. >>>> >>>> Odhaduju, že bude mít jiné vstupy. V obou případech si "vytiskni" vše, >>>> co >>>> leze do konstruktoru třídy Premailer a do té metody a porovnej, budou >>>> tam >>>> rozdíly. >>>> >>>> Nezapomeň na objekty v globálních identifikátorech, které mohou taky >>>> změnit >>>> chování. Django settings je taky globální. Filesystém je globální. >>>> Ovlivněn >>>> může být i kód volaný z modulu premailer.py (nebo jím děděný, nebo i z >>>> něj >>>> děděný) a tedy to hned nevidíš. >>>> >>>> Vytiskni si i výstupy těsně před oběma returny. Je možné, že jsi se >>>> přehlédl a problém bude někde jinde. Mozek je mrška a někdy sám sebe >>>> přesvědčí o nesmyslu. >>>> (http://s2.quickmeme.com/img/fe/fe6a68c7673a3ae9b8856a27ab2ddb >>>> e578daedd9755be7cda3182ed8252d3743.jpg) >>>> >>>> V. >>>> >>>> >>>> On 19.6.2017 07:52, Jan Walter wrote: >>>> > Ahoj, >>>> > mám problém, se kterým si nevím moc rady. Spočívá v odlišnosti >>>> výsledku >>>> > volání jedné specifické metody přes Apache mod_wsgi vs. vývojový >>>> server >>>> > via manage.py runserver (nebo i interaktivní shell) v konzoli. >>>> > >>>> > 1. Django 1.5.4 (vím, není to soudobé). >>>> > 2. Volám metodu transform z premailer knihovny >>>> > (https://github.com/peterbe/premailer/blob/master/ >>>> premailer/premailer.py#L279). >>>> > 3. Když to zavolám pomocí manage.py (runserver nebo shell), funguje >>>> > naprosto OK - distribuuje styly do elementů vstupního dokumentu. >>>> > 4. Když ji volám přes Apache, vrací prázdný řetězec, žádná chyba. >>>> Stejný >>>> > vstup, stejný virtual env. >>>> > >>>> > Máte nějakou ideu, co na to může mít vliv, co by mohlo být jinak, >>>> resp. >>>> > co/jak debuggovat? Jsem už trochu bez nápadů. >>>> > >>>> > Dík moc za případnou inspiraci, >>>> > John >>>> >>>> -- >>>> -- >>>> E-mailová skupina [email protected] >>>> >>> -- -- E-mailová skupina [email protected] Správa: http://groups.google.cz/group/django-cs --- Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs ve Skupinách Google. Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete e-mail na adresu [email protected]. Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAK9Q5BQYbAPp_Q1LktUB1x4i1meoUpNoL-rR-EQHOGq9sgHCSQ%40mail.gmail.com. Další možnosti najdete na adrese https://groups.google.com/d/optout.
