Nodejs kozvetlenul az interneten

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ások

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

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

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).

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

(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.)

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)

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:)

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

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....

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