Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: rade-brno 14. 04. 2013, 22:27:54
-
Dobrý večer,
radil jsem se s kamarádem Googlem, ale zatím jsem nebyl úspěšný... Potřeboval bych na serveru přesměrovat porty jen pro konkrétní doménu (domény), asi bude nejlepší, když uvedu příklad:
Dejme tomu, že u mě hostuje google.com a seznam.cz a mám nainstalovaný Apache2 (port 80) a lighttpd (port 8080).
No a já bych potřeboval, aby když někdo přistupuje na (www.)google.com, aby ho obsloužil Apache2 na portu 80 a když někdo přistupuje na (www.)seznam.cz, aby ho obsloužil lighttpd, poslouchající na portu 8080.
Je toto nějak řešitelné? Předpokládám, že iptables to asi nevyřeší? Když tak stačí jen link, kde mám hledat informace nebo nastínit, přes kterou "službu" by to šlo řešit... Předem díky a příklad je opravdu jen příklad, tak si neťukejte na čelo, co to řeším za blbost... ;)
Radek.
-
Na Apache daj mod_proxy a nastav proxypass, ktory bude presmerovavat vhodne poziadavky.
-
chce to nejakou proxy (treba nginx), ktery bude smerovat jednotlive pozadavky (pro danou domenu presmerujes na localhost:80 a pro jinou na localhost:8080)
treba nejak takhle
server {
listen *:80 default; ## listen for ipv4
server_name domena.tld;
access_log off;
error_log off;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass http://127.0.0.1:8080/;
}
-
Na Apache daj mod_proxy a nastav proxypass, ktory bude presmerovavat vhodne poziadavky.
Super, to zní jednoduše a elegantně, díky moc... ;)
R.
-
To co je pozadovano je nerealne a nesmyslne. Uzivatel (internetovy surfer) se na domenu www.seznam.cz i na www.google.com bude VZDY pripojovat na port 80, pokud explicitne v prohlizeci nezada v adresnim radku jiny port, jako http://www.seznam.cz:8080.
Pokud pouzijete mod proxy nebo cokoli, tak to nejak nechapu cely vyznam, protoze pozadavek na www.seznam.cz bude pak zpracovavat Apache i lighttpd - apache prijme na portu 80 pozadavek, preposle ho pres mod proxy do lighttpd, lighttpd ho zpracuje a vysledek preda apachi, a apache pak vysledek posle ven. Cele se mi to jevi jako zbytecne a neoptimalni.
Pokud ma ten lighttpd webserver na jinem portu slouzit jako "optimalizace" neceho, aby "ulehcil" apache webserveru, tak to naopak bude kontraproduktivni, apache bude zbytecne pouzit pro VSECHNY pozadavky na VSECHNY tak i tak. Mozne reseni by bylo pri prvnim pozadavku na www.seznam.cz apachem vratit 302 redirekci na URL s explicitne uvedenym portem (viz vyse), takze by surfer pak uz vsechny subsekventni pozadavky smeroval primo na ten port s lighttpd aniz by oslovoval apache webserver. Nicmene to asi neni co bysme chteli, protoze uzivatel pak uvidi v adresnim radku prohlizece, ze se pripojuje na nejaky jiny port nez 80.
Jake jsou vlastne puvodni duvody pro pouziti dvou ruznych webserveru?
-
Napriklad to, ze nektere aplikace maji u sebe vlastni webove rozhrani a snazit se to napasovat na uz stavajici webovy soft neni mozne? 8)
-
nektery soft ma v sobe zabudovane lighttpd? :)
-
Taky si říkám, jestli by nestačilo nastavit apache na víc domén. Problém by mohl být pokud by bylo potřeba ssl, ale pak by dotaz nebyl na port 80 ale 443...
-
To co je pozadovano je nerealne a nesmyslne. Uzivatel (internetovy surfer) se na domenu www.seznam.cz i na www.google.com bude VZDY pripojovat na port 80, pokud explicitne v prohlizeci nezada v adresnim radku jiny port, jako http://www.seznam.cz:8080.
Pokud pouzijete mod proxy nebo cokoli, tak to nejak nechapu cely vyznam, protoze pozadavek na www.seznam.cz bude pak zpracovavat Apache i lighttpd - apache prijme na portu 80 pozadavek, preposle ho pres mod proxy do lighttpd, lighttpd ho zpracuje a vysledek preda apachi, a apache pak vysledek posle ven. Cele se mi to jevi jako zbytecne a neoptimalni.
V praxi je tohle docela dost výužíváno a já si naopak neumím představit, že by něco podobného nebylo. Reverzní proxy (Apache, nebo ještě lépe Nginx) příjmá požadavky obecně na portě 80 a podle vnitřní logiky rozhodne, zda požadavek zaslat dále na (další instanci) Apache nebo Lighttpd. :)
-
Reverzní proxy (Apache, nebo ještě lépe Nginx) příjmá požadavky obecně na portě 80 a podle vnitřní logiky rozhodne, zda požadavek zaslat dále na (další instanci) Apache nebo Lighttpd. :)
Ja se snažím pochopit, k čemu by to mělo být dobré. Na co volat přes proxy lighttpd, když už request stejně zpracovává apache? Co lighttpd umí, že to nejde udělat přímo tím apachem? Kvůli výkonu (aby se ulevilo apachi) to být asi nemůže, když to naopak výkon degraduje.
-
o5 přeji dobrý večer... ;)
Původně jsem si říkal, že tato věta:
Předem díky a příklad je opravdu jen příklad, tak si neťukejte na čelo, co to řeším za blbost...
je asi trapná a zbytečná, ale koukám že jsem ji měl zatučnit a začervenat... ;-) :-D :-) Ale je mi jasné, že lidskou zvědavost je potřeba ukojit, takže doufám že Vám své počínání alespoň trochu objasním... ;-)
Jde o to, že si teď platím VPS, kde mi běží Apache2 atd. Teď budu vyvíjet nějakou aplikaci v C++, která bude něco jako Apache - ale velice velice velice optimalizovaná pro jeden konkretní účel a způsob komunikace - PHP a podobné věci nelze vzhledem k požadavkům (je potřeba si mezi relacemi držet určité data v RAM a ne to furt hrkat do DB nebo na disk) použít (dalo by se to teoreticky řešit v Apache JAVOU jako plugin/modul/knihovna či jak to nazvat, ale po zvážení všech pro a proti - rozdíl objemu práce v případě, kdy by se to dělalo v JAVE (pro Apache) a to že se to napíše komplet vše od začátku je zanedbatelný a celý projekt bude méně závislý a více "pod kontrolou") byla zvolena "zelená louka"... Bude to řešit jen některé konkretní věci - je to požadavek (zakázka), tak není důvod spekulovat, zda na to použit něco hotového... No a protože to budu nějakou dobu vyvíjet pouze na lokálu a pak to budu chtít testovat třeba 3 měsíce v reálném provozu a nebudu chtít platit další VPS, tak mě napadlo to chvíli provozovat takto paralelně s tím, že až bude vše odladěno, tak už to nebude potřeba a poběží to někde "normálně"... :-)
R.
PS: Ještě trochu off topic otázka, když budu mít uzavřený (komerční) program a budu do něj linkovat knihovny, které jsou nainstalované v systému (gzip, openssl), naivně předpokládám, že to není problém...???
-
Ja se snažím pochopit, k čemu by to mělo být dobré. Na co volat přes proxy lighttpd, když už request stejně zpracovává apache? Co lighttpd umí, že to nejde udělat přímo tím apachem? Kvůli výkonu (aby se ulevilo apachi) to být asi nemůže, když to naopak výkon degraduje.
Právě ta zmíněná fexibilita ve smyslu skrytí vnitřní infrastruktury, částečného rozložení zátěže a jasného rozdělení úloh? Na reverzní proxy lze delegovat např. věci kolem SSL certifikátu a šifrování, což mi přijde dost zajímavé. Samotné výkonné web servery se pak mohou věnovat svému poslání, nemusí být zatíženy nadbytečnou konfigurací a neřešit věci, které lze řešit poměrně elegantním způsobem centrálně na proxy.
Příklad: interně provozuji X samostatných web serverů/aplikací (postupně přibývají další) a chci je pustit do světa pod společnou doménou, IP, na společném standardním portu a chci použít https. K faktickému rozlišení aplikací chci použít URL, např. https://mojedomena.cz, https://mojedomena.cz/app1, https://mojedomena.cz/app2 atd. Bez reverzní proxy, nebo ekvivalentu upřímně nevím, jak toto vyřešit, to snad ani nelze (zdůraznuji přítomnost https ssl). Jasná úloha pro reverzní proxy.
S tímto konceptem se teprve seznamuji a chystám se na realizaci výše uvedeného scénáře. Určitě se ale najdou i další pádné argumenty ve prospěch reverzní proxy. :)
-
Ja se snažím pochopit, k čemu by to mělo být dobré. Na co volat přes proxy lighttpd, když už request stejně zpracovává apache? Co lighttpd umí, že to nejde udělat přímo tím apachem? Kvůli výkonu (aby se ulevilo apachi) to být asi nemůže, když to naopak výkon degraduje.
Právě ta zmíněná fexibilita ve smyslu skrytí vnitřní infrastruktury, částečného rozložení zátěže a jasného rozdělení úloh? Na reverzní proxy lze delegovat např. věci kolem SSL certifikátu a šifrování, což mi přijde dost zajímavé. Samotné výkonné web servery se pak mohou věnovat svému poslání, nemusí být zatíženy nadbytečnou konfigurací a neřešit věci, které lze řešit poměrně elegantním způsobem centrálně na proxy.
Příklad: interně provozuji X samostatných web serverů/aplikací (postupně přibývají další) a chci je pustit do světa pod společnou doménou, IP, na společném standardním portu a chci použít https. K faktickému rozlišení aplikací chci použít URL, např. https://mojedomena.cz, https://mojedomena.cz/app1, https://mojedomena.cz/app2 atd. Bez reverzní proxy, nebo ekvivalentu upřímně nevím, jak toto vyřešit, to snad ani nelze (zdůraznuji přítomnost https ssl). Jasná úloha pro reverzní proxy.
S tímto konceptem se teprve seznamuji a chystám se na realizaci výše uvedeného scénáře. Určitě se ale najdou i další pádné argumenty ve prospěch reverzní proxy. :)
Jestli to chápu dobře, tak řešením by možná bylo toto:
https://mojedomena.cz
https://app1.mojedomena.cz
https://app2.mojedomena.cz
Radek
-
Jestli to chápu dobře, tak řešením by možná bylo toto:
https://mojedomena.cz
https://app1.mojedomena.cz
https://app2.mojedomena.cz
Radek
Pouze zdánlivě.
1) Problém s SSL certifkátem. Musel by být vydán ve variantě *.mojedomena.cz => řádově dražší záležitost.
2) Nějaký prostředník by musel odposlouchávat komunikaci a podle URL v http požadavku směrovat komunikaci na podřízené servery (app1, app2). Zde je problém se šifrovanou komunikací, ta se dost blbě odposlouchává. Případně by prostředník musel zajišťovat šifrování ve vlastní režii způsobem, který je kompatibilní s podřízenými servery.
3) Jsme u reverzní proxy, která přímo nabízí řešení pro uvedené trable. :)
-
To co je pozadovano je nerealne a nesmyslne. Uzivatel (internetovy surfer) se na domenu www.seznam.cz i na www.google.com bude VZDY pripojovat na port 80, pokud explicitne v prohlizeci nezada v adresnim radku jiny port, jako http://www.seznam.cz:8080.
A proč by to mělo být nemyslitelné a nereálné?
Dejme pouhý příklad. Stavíme univerzální stroj, který kromě vlastních stránek má ještě webový management pro každou svou službu, kde každá služba má svůj port a svůj vlastní management. Ono je otravné, když musíte na každou službu přistupovat na jiný port, tak uděláte to, že zapojíte mod_proxy, ať již na lighttpd či na apache, tyto služby dáte na loopback a postaráte se o to, aby ty služby byly přítomny pod jedním portem, jednou službou - uživatel bude mít pocit, že vše je homogenní a bude šťastný.
třeba:
http://doména/ <-- vaše stránky
http://doména/management-služby1
http://doména/management-služby-n
A to, na co se ptá tazatel, je to samé, jen v jiné variantě.
Tedy pro tazatele - ano, já bych volil reverzní proxy.
-
Jestli to chápu dobře, tak řešením by možná bylo toto:
https://mojedomena.cz
https://app1.mojedomena.cz
https://app2.mojedomena.cz
Radek
Pouze zdánlivě.
1) Problém s SSL certifkátem. Musel by být vydán ve variantě *.mojedomena.cz => řádově dražší záležitost.
2) Nějaký prostředník by musel odposlouchávat komunikaci a podle URL v http požadavku směrovat komunikaci na podřízené servery (app1, app2). Zde je problém se šifrovanou komunikací, ta se dost blbě odposlouchává. Případně by prostředník musel zajišťovat šifrování ve vlastní režii způsobem, který je kompatibilní s podřízenými servery.
3) Jsme u reverzní proxy, která přímo nabízí řešení pro uvedené trable. :)
1) Ano, ale otázka peněz nebyla původním argumentem (důvodem) tohoto řešení - bavíme se o tom, jestli to jde, ne...??? ;-)
2) Pravděpodobně máte pravdu, že to bez proxy není řešitelné - leda že by se to řešilo přes DNS a IP adresy (možná že by to šlo nějak elegantně vyřešit šikovným záznamem v DNS - využít nějaké fičurky, na kterou by pak šlo třeba navázat nějaké pravidlo v iptables? - ale s DNS umím jen základy, takže pouze spekuluji)...
3) Souhlasím...
R.
-
1) Problém s SSL certifkátem. Musel by být vydán ve variantě *.mojedomena.cz => řádově dražší záležitost.
Nemusel. Existují také SSL certifikáty s více doménovými jmény.
-
Aha, tak to jsme si zcela nerozumněli. Pohlížel jsem na věc optikou praxí prověřené proveditelnosti, vhodnosti a efektivity.
Jistěže existuje SSL certifikát pro více domén. Ne každý vydavatel ovšem danou možnost nabízí. Dále je počet domén v takovém certifikátu omezen a pružné přidávání dalších domén je problematické, ne-li rovnou nemožné. Navíc je tu finanční stránka. To by jeden musel být masochista.
Mimochodem, má smysl vytrhávat jednotlivé věty mého příspěvku a k těm předkládat alternativy, které v širším kontextu alternativami vlastně nejsou?
Jinak souhlas se strašidlem, to je přesně ono :)