Nodejs kozvetlenul az interneten

 ( tompos | 2016. február 24., szerda - 21:39 )

Nem vagyok jartas a nodejs-ben, viszonylag tapasztalatlan vagyok benne.

Mennyire problema, mennyire jo kirakni nodejs alkalmazast kozvetlenul a netre, vagy inkabb ele rakni egy nginx v. apache proxy-t?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Egy proxy (pl. nginx) adott esetben meg tud fogni par dolgot, amit a NodeJS nem, de nem ezert szokas proxyzni, hanem mert ahol egy NodeJS alkalmazas van, ott tobb is lehet, es ha van proxyd, konyebb boviteni.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

OK, nyilvanvalo, h konnyebb v. egyaltalan lehet egyszeruen limiteket megadni nginx-szel.
Tobb alkalmazas nincs.

De mik igazabol azok, amiket meg tud fogni az nginx? Biztonsagosabb lenne valoban?

Biztonságosabb nem lesz, egy túlterheléses támadást tudsz könnyebben levédeni vele (nginx speciális 444-es response kóddal). A nodeJS pont ugyanúgy viselkedik, mint egy Apache+php, csak gyorsabb a fork-ja és egyszerűbb.

--------------------------------
www.symbolcloud.hu

> csak gyorsabb a fork-ja és egyszerűbb.

wtf?

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

1. Gyorsabb, de facto.
2. fork-ja = működése, "szálasodása", beérkező kérések kezelése, stb.

akkor nevezd az utobbinak, de ne forknak


// Happy debugging, suckers
#define true (rand() > 10)

node.js-ben nincs thread/szalasodas/fork egyelore.
Pont ez a lenyeg az egeszben. Van egy mainloop, es minden aszinkron.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

valahol egyszer azt olvastam, hogy az nginx is event loop elvű

Processzekkel és threadekkel. tada! :)

Akkor is kap a felhasználó valamit az arcába, ha a node történetesen elszáll.
Jobb skálázhatóság: nginx beléphet load balancer szerepbe anélkül, hogy bármit nagyon átalakítanál, így tetszőleges mennyiségű "app szervert" indíthatsz el ha kell.
Később bizonyos funkciók szabadabban átszervezhetők:
/xy/* => proxy x node szervernek
/kz/* => proxy n node szervernek

Statikus anyagok azonnali kiszolgálása. Access log.
Socket.io használható nginx-szel és express (node http) szerverrel is.
Ilyenek jutnak eszembe így elsőre.

Nincs lb, nincsenek szukseg statikus anyagok kiszolgalasara. Ezek mind kezenfekvo dolgok. Engem itt most kizarolag az apache/nginx vs. naked nodejs kerdeskor erdekel.

Abban viszont igazad van, hasznos, h kap hibauzenetet akkor is, ha a node nem megy (az elszall kevesbe erdekes, mint a karbantartas, ami viszont mindig van termeszetesen).

Nincs a html felülethez stíluslap? (jobban belegondolva, ha API akkor nincs :))

Van, de nincs szukseg azt statikusan kiszolgalni. Azzal miert lennek elobbre?:)
Nem egy tomegtermek.

mint masok is irtak

- Ha mondjuk sslt szeretnel appod ele tenni, akkor nginxben/haproxyban tudod bekapcsolni es igy kozos helyen van ocsp + cert configok.

- Masik elonye nginx/haproxynak(ha ugyan azon a gepen van, mint nodejs): Atlag fosadek fejleszto nem kezeli le, ha csak ugy eltunik valaki, tehat egy adott socketen nincs tobb forgalom (se connection reset se semmi), tehat nincs tobb event, akkor az a socket egeszen odaig ott be lesz ragadva szepen.
Ha nginx van elotte, akkor az kezel timeoutot alapbol es ha a kliensel megszakad kapcsolata, akkor backendet is ertesiti rola es general legalabb egy connection resetet, amire mar valoszinu le lesz kezelve appban.

- Lesz syslog error es accesslogrol is. Ez megint debughoz hasznos, mert latod mennyi ideig tartott egy backend hivas vagy, hogy egyaltalan miert nem sikerult.

- Legalabb lesz vmi errormessage, ha vmiert nem mukodik nodejs.

- Limitek.

> - Ha mondjuk sslt szeretnel appod ele tenni, akkor nginxben/haproxyban tudod bekapcsolni es igy kozos helyen van ocsp + cert configok.

A nodejs is tud ssl-t.

> Atlag fosadek fejleszto nem kezeli le, ha csak ugy eltunik valaki, tehat egy adott socketen nincs tobb forgalom (se connection reset se semmi), tehat nincs tobb event, akkor az a socket egeszen odaig ott be lesz ragadva szepen

Bar sosem vizsgaltam a kollegat ebbol a szempontbol, tegyuk fel, hogy nem fosadek:D

> Legalabb lesz vmi errormessage, ha vmiert nem mukodik nodejs.

Ezt nem ertem, wtf?

"A nodejs is tud ssl-t."
Biztosan. Perlben is lehet irni https servert. De ezt inkabb mukodo dolgokra kell bizni ahol performance is szempont volt, nem csak osszehanyas. Meg ha kijott spdy meg kijott http2 meg quic meg stb, akkor majd egy elfeledett nodejs appot biztosan atirjak.

"Bar sosem vizsgaltam a kollegat ebbol a szempontbol, tegyuk fel, hogy nem fosadek:D"
Ha php fejleszto volt vagy valami hasonloan ertelmes nyelve, ahol nem volt tapasztalata daemonokkal csak 1 szalon lefuto cuccokkal amiket amugyis lekillelt x ido utan apache vagy fpm, akkor altalaban azzal kezdodik, hogy 1 het production futas utan fixaljak ezeket :)

"> Legalabb lesz vmi errormessage, ha vmiert nem mukodik nodejs."
Ha barmilyen softerror van, es http es nem 200akat valaszol szerencsetlen vagy lassabban mint eddig, akkor van egy fuggetlen logod, ahol latod ezeket.Vagy mondjuk eddig 123 byteot valaszolt 6 es 8 ora kozott unnepnapokon viszont a trend megvaltozott, akkor megint kezdheted sejteni, hogy baj van fuggetlenul attol, hogy app azt hiszi sajat magarol, hogy mukodik.

> Biztosan. Perlben is lehet irni https servert. De ezt inkabb mukodo dolgokra kell bizni ahol performance is szempont volt, nem csak osszehanyas. Meg ha kijott spdy meg kijott http2 meg quic meg stb, akkor majd egy elfeledett nodejs appot biztosan atirjak.

Ezt nem ertem.

Azt allitod, nem szabad uj alkalmazasokatat (tortenetesen webszervert irni?).

> Ha php fejleszto volt vagy valami hasonloan ertelmes nyelve, ahol nem volt tapasztalata daemonokkal csak 1 szalon lefuto cuccokkal amiket amugyis lekillelt x ido utan apache vagy fpm, akkor altalaban azzal kezdodik, hogy 1 het production futas utan fixaljak ezeket :)

Nem enyhe eloiteleted van. Mondom megegyszer, tegyuk fel, h a kollega/kollegak nem fosadek(ok). Ez az alap. Ha neked mas a tapasztalatod a sajatjaiddal, azt a te bajod:)

> Ha barmilyen softerror van, es http es nem 200akat valaszol szerencsetlen vagy lassabban mint eddig, akkor van egy fuggetlen logod, ahol latod ezeket.Vagy mondjuk eddig 123 byteot valaszolt 6 es 8 ora kozott unnepnapokon viszont a trend megvaltozott, akkor megint kezdheted sejteni, hogy baj van fuggetlenul attol, hogy app azt hiszi sajat magarol, hogy mukodik.

Ha jol ertem, azt probalod megfogalmazni, hogy ha a nodejs baszakszik, azt a proxy megmutatja.
Mi mutatja meg azt, ha a proxy baszakszik? Az ele is tegyek egy masik proxy-t?

De, lehet, de ha webszervert irsz, akkor abba szignifikans energiat kell beletenni, mert kozel sem trivialis. Az nginx-nek is hosszu-hosszu evek kellettek ahhoz, hogy kiforrjon egy olyan szintre, hogy lehessen hasznalni.

Ha megnezed pl. az Express issue listajat, meg olyan alap dolgokkal kuzdenek, mint a fejlesztesi modszertan, es jopar HTTP implementacioval kapcsolatos issue is nyitva van.

Sajnos a JS libek nagyon nagy szazalekara igaz az, hogy valaki osszekalapal egy MVP-t, es utana csak nagyon lassan "javulnak meg" a kozosseg altal kevesbe fontosnak itelt, am a kompatibilitashoz elengedhetetlen funkciok.

Ugyanez igaz a sajat kododra is. Ha pl. most lefejlesztesz egy alkalmazast 4-es Expressre, es jovore bele akarsz rakni - teszem azt - HTTP/2 tamogatast, lehet, hogy at kell allitanod az alkalmazasodat Express 5-re, ami mas reszeket is erint. Sokkal egyszerubb bedobni ele egy proxyt, ami megoldja az ilyen trivialitasokat.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Ja, igy mar ertheto, amit irsz.

De ebbol nezve a nodejs az nginx mogott sem OK, nem?

(Nem kedvelem a nginx-et...)

Ha frontend, akkor HaProxy-nál nem nagyon van időtállóbb sztori. ;) Néhány gépemen még az ssh-k is azon keresztül mennek a júzereknek, a stat oldala kiváló monitor (pl. icinga) előtét stb. :DDD

(Tudok adni 100%-ban friss, statikus ssl-es, luá-s verziót (libre és open is van) ami megy már több hete prod környezetben is - ha érdekel. Egy bináris + 1konfig é sannyi.)

azért a megszállottságnak is van határa.
Dev ágat nem véletlen nem használunk prod környezetben, de igazából te dolgod, mindenki úgy baszik ki magával ahogy akar;)


// Happy debugging, suckers
#define true (rand() > 10)

Dev ágat nem is. ;) Honnan jött a dev ág..? :O

Onnan hogy kicsit lemaradtam, utoljára mikor néztem akkor még csak dev ágban volt lua support, szóval akkor tárgytalan a trollkodásom, bocsi;)


// Happy debugging, suckers
#define true (rand() > 10)

:) Átnézek nginx háztájra a 7végén. ;)

Mind haproxy-t, mind nginx-et használok. Nginx-et kiszolgálás miatt többet piszkálom, haproxy-t egyszer belőttem azóta csak frissítgettem (ezért maradtam le;)). Mindkettővel elégedett vagyok, de igazából egyik nem váltja ki a másikat, mert véleményem szerint mindkettő teljesen másra való.
A haproxy ahogy a nevében is benne van, HA környezetbe, HA funkcionalitásra használni. nginx-et nem használnék erre, mert nem erre való, annak a proxy featureje sem erre van kitalálva, hanem arra hogy egy applikációs csomag része legyen. Pl.: weboldal, oldalak php-val generálva (proxy 1 php-fpm irányába), mellette websocket backendnek nodejs (proxy 2), a static dolgok pedig kozvetlen nginx-ből. Aztán ha ebből az app csomagból széltében akarok skálázódni, akkor felhúzok még 10 ilyen nginx környezetet és haproxy-val összehúzom őket:)


// Happy debugging, suckers
#define true (rand() > 10)

:D Jaja, nekem is ezek rémlenek - haproxy-t beállítom oszt ketyeg mint a kisangyal - több generációnyi backend-et kiszolgál (és megvéd). Nna, vasárnapra már rezerváltam időt nginx tudás aktualizálásra (milyen új pluginek stb.)... :DDD

a tobbire janoszen valaszolt

"Ha jol ertem, azt probalod megfogalmazni, hogy ha a nodejs baszakszik, azt a proxy megmutatja."
Igen.

"Mi mutatja meg azt, ha a proxy baszakszik? Az ele is tegyek egy masik proxy-t?"
Nginx vagy haproxynal nagyon kicsi az esely, hogy szar legyen alap http/https eseten. Mert foleg ez a feladatuk az elejetol fogva es rengeteg ember tesztelni. Viszont egy uj appnal barmi lehet hibas. Es akar egy express libet sem hasznalnak annyian, mint mondjuk nginxet.

Ebben annyi HA van, hogycsakna.

Perpillanat ott tartunk, hogy a nodejs is latszolag rendben mukodik. Amikor elekerul az nginx, akkor viszont elkezdenek bonyolodni a dolgok.
Szerepelt itt a threadben nehany nyilvanvalo es nehany kevesbe ertelmu vagy epp mondvacsinalt elony, de kozben van a proxy-zasnak hatranya is. Nem egyertelmu szamomra tovabbra sem, hogy sokkal rosszabb a helyzet, ha nativan ott van a neten.

Egyik se mondva csinalt ok foleg amit en linkeltem. Te megkerdezted a velemenyunket. Addig lesz ez a velemenyed amig

1. valaki meg nem talalja es elnem kezdi tamgadni.
2. Szurni akarsz bizonyos requesteket
3. Jobb helyeken van WAF a nodejs elott

Nem kell nekunk hinni csak lehetseges ,hogy nagyobb a tapasztalatunk ebbe mint neked es tapasztalatbol beszelunk.

Amugy uzemeltetek egy 50+ kompensu nodejs rendszert.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Elhiszem neked, h jobban ertesz hozza, de amiket irtatok (ahogy irtam), javareszt egy ha.
HA nem szabvanyos. Ha nagyanyam nagy es sarga lett volna, meg csilingel, akkor beallhatott volna a korutra villamosnak.

A kerdes szerintem az, hogy tartja a szabvanyt a nodejs vagy nem? Ha nem, akkor lehet beszelni rola, hogy a tobbihez kepest mennyire es miben nem, majd az alkalmazas valos eletere milyen hatassal van.

> valaki meg nem talalja es elnem kezdi tamgadni.

Kerdezhetnem ugy is, hogy konnyebb (nem az, hogy lehet, hogy konnyebb-e) tamadni a nodejs-t, mint egy 1 proxy-t?

> 3. Jobb helyeken van WAF a nodejs elott

Jobb helyeken barmi elott van waf. Az apache, az nginx es a haproxy elott is. Jobb helyeken a waf meg a user kozott ott van egy waf, legfeljebb a tuloldalon.
De nem ez a kerdes:)

Ki kene tesztelni, de eleg biztos vagyok benne, hogy bizonyos invalid HTTP keresekre az nginx elhajt 400-as hibaval, a NodeJS / Express meg megprobalja kiszolgalni.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Nna, ez az igazi kerdes, hogy csinalt-e mar vki ilyet.
Nem a jelenlevok kozul, hanem ugy altalaban, mondjuk egy random kotekedo troll audit ceg. Ha nem, vajon miert nem?

En azert nem, mert nincs olyan projektem, amin NodeJS-t hasznalnank. (Ennek meg az az oka, hogy a NodeJS fejlesztok nagy resze ugy ir programot, hogy "Jaj, techunk moge forever JS-t, majd ha lerohad, induljon ujra". Right.)

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Egyszer neztem a forevert, de nem hasznalom. Akkor ez az alkalmazas vajon magasabb minosegi szintet kepvisel?:)

Van ugy, hogy tenylegesen elszall a node.js, es akkor timeout van.
De ha van elotte egy reverse proxy, akkor legalabb egy hiba html-t megjelenit.

Olyanba meg nem futottam bele, hogy a node.js nem tudott volna valami http kerest kiszolgalni (get, post, put, delete), es emiatt kellett volna reverse proxy ele.

Viszont olyanba mar belefutottam, hogy reverse proxy alapbeallitaskent 1MB-os fajlt enged tovabb, igy nem lehetett egy sima fenykepet (3.6MB) feltolteni a weboldalra. UGyanigy nem lehetett letolteni egy 7.6GB-os fajlt.
(mondjuk ott a nodejs-be is bele kellett nyulni, hogy hajlando legyen kiszolgalni).

Ha egy raspberry pi-on elfuto valami kis hobbi dolog van, akkor nem szorakoznek reverse proxyval elotte (pl. homersekletkijelzo a szobaban)

De ha van mar egy adatbazis is (mongodb tipikusan), akkor mar reverse proxy-t is tennek.

Van egy komolysagi fok na. Egyebkent reverse proxy-val tudsz load-balancingolni is.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Egy ideig zavart az nginx hülyesége, hogy ilyen alacsony a client_max_body_size, de most már rutinból tervezek azzal, hogy milyen felhasználáshoz lesz és oda milyen méretek kellenek.

[TROLL]-1 nginx-re :DDD [/TROLL]

Ismerem a haproxy-t, remek dolog. De nem az a kerdes, h az milyen jo.

Az viszont erdekelne, h az nginx miert rossz.

A "nem kedvelem" != "rossz". ;) Mondjuk a haproxy tcp szinten is jól mozog, az nginx asszem nem...

A zimbra-ban tuti az van az imap/pop3 forwardra, nem hiszme, hogy protokoll szinten csinalna. De sosem probaltam. mondjuk en eleve nem akarok ssh-t proxy-zni, nem latom ertelmet.

Szoval ok, nem rossz, miert nem kedveled? Meg mindig nem az erdekel, h a haproxy-t kedveled-e:)

Haproxy-zok 2004 óta élesben. Nginx nem ad nekem semmi pluszt (nem is tudom mikor láttam először - 2010 talán? Hátast nem dobtam tőle akkor sem. Maradt a lighttpd ott ahová nem akartak apache-ot.), nem rajzolnám át a világom. Ennyi. :D

pl. slow request DOS-al siman padolra teszik az alkalmazasod.
HTTPS lebontasra se a legjobb.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

> pl. slow request DOS-al siman padolra teszik az alkalmazasod.

Az igazsag az, h ha le van dos-olva, akkor le VAN dosolva. Tokmind1 (majdnem), h a nodejs hal bele, vagy az nginx.

> HTTPS lebontasra se a legjobb.

Ezt nem ertem, kifejtened?

SSL offload-ra sztem sem való webszerver. (Egy HaProxy hívő. :DDD (Az említett típusú DDoS-t is pl. egész jó elnyeli. ;) -> http://blog.haproxy.com/2012/02/27/use-a-load-balancer-as-a-first-row-of-defense-against-ddos/ ))

Ahh, mar ertem.
Konkretan ebben az esetben irrelevans, nem annyira erdekes szamomra. Majd idovel lehet, az lesz.

Ez nem olyan DOS mint amire Te gondolsz.

https://blog.qualys.com/securitylabs/2011/11/02/how-to-protect-against-slow-http-attacks

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer