Mode a environment, console vs. production vs. development

edke

Ahojte.

Uz dlhsiu dobu intenzivne pracujem s cli pri mojich webovych aplikaciach. S hostingom a shell-om nemam problem, hostujem na vlastnych servroch, preto shell pri deploymente plne vyuzivam a povazujem to za nutnu podmienku pre deployment. Zakazku, ktoru by som mal riesit bez moznosti shell-u na production servri odmietnem.

Problem, ktory aktualne mam s implementaciou modes v Environment je ten, ze mode CONSOLE sa povazuje za rovnocenny stav k modom PRODUCTION a DEVELOPMENT, co je podla mna a mojej implementacie chyba a problem.

Cli a teda CONSOLE je len jeden sposob k pristupu k aplikacii. Aktualne hlavny subor, ktory nastavuje prostredie je u mna bootstrap.php. Tento subor sa vseobecne vyuziva vo vsetkych moznych pristupoch k aplikacii.

Mozne (a mnou pouzivane) pristupy k aplikacii:

cez http:// a webovy server, pristupovy bod je samozrejme index.php v document_root a nasledne bootstrap.php.
cez phpunit, ako bootstrap sa vyuziva bootstrap.php
vsetky cli skripty

CONSOLE mode je teda vyuzivany rovnako v production mode ako aj v development mode. A aby bolo mozne vyuzit silu konfiguracie, toto predstavuje problem, pretoze v CONSOLE mode je stale konfiguracia nastavena len pre blok [console], v aktualnom stave sa neda aplikovat rozlisenie PRODUCTION a DEVELOPMENT.

Pre ich uspesne nastavenie je potrebna IP, ktoru pri volani cez webserver je jednoducho dostupna cez $_SERVER, co samozrejme v cli nie je dostupne. V CLI ale celkom uspesne vyuzivam konstrukciu:

$addr = getHostByName(getHostName());

, ktora potom pri rovnakom algoritme ako to ma David implementovane pri autodetect-e pekne rozlisi development aj production pre CONSOLE mode. A tato konstukcia mi pekne funguje ako pod linuxom, tak pod windows.

Toto teda teraz obchadzam tym, ze v bootstrap-e pre CONSOLE natvrdo nastavujem Environment::setMode() a environment premennu ‚environment‘, tym padom mam aj v CONSOLE Mode spravny test Environment::isProduction(). A Environment::isConsole() ostava len ako test, co je spravne.

Teda zhrnutie mojich letanii na zaver, berte toto ako ziadost o zmenu a predtym samozrejme ako predmet na diskusiu:

Mode bez ohladu nato, ci sa jedna o webrequest alebo CLI spustenie by vzdy vracal development/production.
Na detekovanie ci sa jedna o CLI by ostalo aktualne Environment::isConsole().

S tymto suvisi aj fakt, ze blok [console] v config.ini by vlastne stratil zmysel. Ja ani neviem prist na situaciu, kedy by som to vyuzil, pouzivate to vy ?

srigi

Osobne som sa s tymto tiez stretol a ja by som dokonca potreboval v configu rozlisenie na consoleDevelopment a consoleProduction.

Patrik Votoček

taky sem se s tim setkal https://forum.nette.org/…rametr-v-cli a trochu souvisejici https://forum.nette.org/…vani-ladenky

pekelnik

Toto je poměrně dlouhodobá záležitost… Osobně bych byl také pro. David argumentuje tím že mód můžeš podstrčit parametrem. php index.php --mode production

Patrik Votoček

tak o této možnosti slyším poprvé

edke

pekelnik wrote:

Toto je poměrně dlouhodobá záležitost… Osobně bych byl také pro. David argumentuje tím že mód můžeš podstrčit parametrem. php index.php --mode production

Ale v zmysle, ze si to mam dalej sam spravovat ako argument, alebo sa o takuto detekciu stara sam Environment ? Ale v oboch pripadoch → tak to dakujem pekne :) Radsej to budem detekovat automaticky cez IP adresu hostu v bootstrap-e, ak ako to riesim teraz.

Editoval edke (24. 3. 2011 14:50)

Elijen

pekelnik napsal(a):

Toto je poměrně dlouhodobá záležitost… Osobně bych byl také pro. David argumentuje tím že mód můžeš podstrčit parametrem. php index.php --mode production

Právě tento problém řeším a --mode prouction mi bohužel nefunguje. Vypadá to, že ho Nette (2.0 beta) ignoruje. Ta automatická detekce prostředí je tak trochu dvousečná zbraň. Mnohem lepší mi přijde detekce prostředí ala Zend Framework, kde se nastavení provádí pomocí environment proměnné apache.

Osobne som sa s tymto tiez stretol a ja by som dokonca potreboval v configu rozlisenie na consoleDevelopment a consoleProduction.

+1

Editoval Elijen (22. 11. 2011 11:57)

Patrik Votoček

Elijen napsal(a):

Mnohem lepší mi přijde detekce prostředí ala Zend Framework, kde se nastavení provádí pomocí environment proměnné apache.

K čemu ti bude environment proměnná v Apache u CLI scrpitu? :-)

BTW nic ti nebrání si to implementovat:

$container = $configurator->loadConfig(__DIR__ . "/config.neon", isset($_ENV['mode']) ? $_ENV['mode'] : NULL);

Osobne som sa s tymto tiez stretol a ja by som dokonca potreboval v configu rozlisenie na consoleDevelopment a consoleProduction.

Jak chceš tyhle dva módy detekovat?

paranoiq

ad „--mode production“ – je obvyklé, že konzolové nástroje mají právě debug mód (nikoliv produkční) aktivován parametrem

bylo by asi nejlepší celou tuhle detekci módů vytrhnout z Nette\Configurator a ostatních míst a umožnit její překrytí vlastní implementací

pár poznámek (hlavně pro mě, abych si to srovnal v hlavě. ve většině to odpovídá současnému přístupu Nette):

celá věc okolo módů atd má tři rozměry:

způsob zpracování vstupů/výspupů/chyb: http | http/ajax | console …
režim zobrazení chyb: user | developer (production | development)
konfigurace prostředí (hesla, adresy, služby…): stroj vývojáře | staging | produkce

bod 1. nijak nesouvisí s 2. a 3.

bod 2. a 3. spolu ne úplně souvisí – pro vývojáře je občas nutné fixnout něco na produkci v development režimu, nebo naopak prohlédnout chybové stránky na vývojovém stroji v production režimu. na stagingu je také třeba oboje

detekce 1. je celkem jasná

detekovat režim 2. na http je snadné (localhost nebo výčet adres vývojářů), ale mělo by jít autodetekci obejít (např. cookie od uživatele s definovanou IP adresou – vývojáře). v konsoli bych zvolil jako defaultní production a development rozpoznával parametrem (třeba --debug)

jméno prostředí 3.,

buď musí přijít z konfigurace – což souvisí s includováním NEON souborů, které není dořešeno (třeba local.neon)
nebo naopak přijde od stroje na kterém aplikace běží a ovlivní konfiguraci (php_uname() nebo getHostName())

byl bych spíš pro b) – na základě jména stroje rozhodnout co z konfigurace načíst. což je v podstatě současný stav

Elijen

Patrik Votoček napsal(a):

K čemu ti bude environment proměnná v Apache u CLI scrpitu? :-)

Jasně, tohle by se muselo detekovat zas nějak jinak. Třeba přes environment proměnnou shellu.

BTW nic ti nebrání si to implementovat:

Implementované to mám. Zatím provizorně podle hodnoty getHostName(), ale problém není pouze v načtení správného configu. (paranoiq to vystihl vcelku dobře) Nevidím uplně do vnitřností frameworku, tak jsem se omezil na předání sekce metodě loadConfig(). Až bude čas, tak se pokusím sesmolit nějaké finální řešení.

David Grudl

Podle paranoiqa jsem detekci režimu development/production zjednodušil tak, že jen 127.0.0.1 (nebo ::1) se považuje za development, vše ostatní (včetně console režimu) jako production.

V případě konzolových aplikací mi připadá vhodnější používat přepínač v příkazové řádce než nějakou magii.

Zároveň jsem vyhodil sekci ‚console‘ z konfiguráku, takže konzolová aplikace bude standardně jako production.

Dalibor

David Grudl napsal(a):

Podle paranoiqa jsem detekci režimu development/production zjednodušil tak, že jen 127.0.0.1 (nebo ::1) se považuje za development, vše ostatní (včetně console režimu) jako production.

Dá se nějak Nette natlačit development mód nasílu? Já používám vývojový server na 192.168.0.0 síti a tento „upgrade“ mi zamíchal s kartama.. A to jsem se už popral s novým pojetím konfiguráku.. ;-)

Aurielle

Jde ti o Laděnku nebo o načítání config.neon?

Laděnka:

Nette\Diagnostics\Debugger::enable(Nette\Diagnostics\Debugger::DEVELOPMENT);

Načítání configu:

$configurator->loadConfig(__DIR__ . '/config.neon', 'development');

David Grudl

Pro konfiguraci takto:

$configurator->setProductionMode(FALSE);

David Grudl

Pokud by někdo nerozuměl, proč se Laděnka a konfigurator nastavují odděleně, je to z toho důvodu, že Laděnka souvisí s laděním, konfigurace s tím, kde aplikace běží a jak se chová. I na ostrém serveru lze ladit a stejně tak i na vývojářské mašině nás zajímá, jak se aplikace chová v ostrém provozu.

Dalibor

Aha, díky, nevěděl jsem, že se nastavuje zvlášť laděnka a konfigurace..

Dalibor

Tohle ruční editování ale stejně řeší problém jen částečně, protože budu muset detekovat production/development mód sám.. Jak píše Paranoiq:

„bylo by asi nejlepší celou tuhle detekci módů vytrhnout z Nette\Configurator a ostatních míst a umožnit její překrytí vlastní implementací“

by asi opravdu bylo nejlepší..

urbasekd

Já přistupuju k CLI pomocí ANTu jak na produkčním serveru, tak na svým počítači, a tak jsem chtěl automatickou detekci prostředí (nastavení databáze) i u CLI. Napsal jsem to do bootstrapu takto:

if (PHP_SAPI == 'cli' && Nette\Utils\Strings::startsWith(getHostByName(getHostName()), "192.168."))
	$configurator->addConfig(__DIR__ . '/config/config.neon', $configurator::DEVELOPMENT);
else
	$configurator->addConfig(__DIR__ . '/config/config.neon');

Možná to není ideální řešení, ale funguje to.