Lopullinen Node.js-tuotannon tarkistuslista

Teetkö tämän Node-asian suoraan tuotannossa? Katsotaanpa joitain yleisiä virheitä, joita ihmiset tekevät Noden käyttämisessä tuotantoon (tulevat suoraan omista projekteistani - kuten codedamn) ja miten niitä voidaan lieventää.

Voit käyttää tätä tarkistusluettelona tuotannossa, kun otat käyttöön Node-sovelluksia. Koska tämä on tuotantovalmiita käytäntöjä käsittelevä artikkeli, monia niistä ei sovelleta, kun kehität sovelluksia paikalliseen järjestelmään.

Suorita solmu klusterimoodissa / erilliset solmuprosessit

Muista, että solmu on yksisäikeinen. Se voi delegoida monia asioita (kuten HTTP-pyynnöt ja tiedostojärjestelmän lukeminen / kirjoittaminen) käyttöjärjestelmälle, joka käsittelee niitä monisäikeisessä ympäristössä. Mutta silti kirjoittamasi koodi, sovelluslogiikka, toimii aina yhdessä säikeessä.

Suorittamalla yhdessä ketjussa solmuprosessi rajoittuu aina vain yhteen koneen ytimeen. Joten jos sinulla on palvelin, jossa on useita ytimiä, tuhlataan laskentatehoa, kun Node toimii vain kerran palvelimellasi.

Mitä "solmun käyttäminen vain kerran" tarkoittaa? Käyttöjärjestelmissä on sisäänrakennettu ajoitin, joka on vastuussa siitä, kuinka prosessien suoritus jakautuu koneen suorittimille. Kun suoritat vain 2 prosessia 2-ytimisessä koneessa, käyttöjärjestelmä määrittää, että on parasta suorittaa molemmat prosessit erillisillä ytimillä maksimaalisen suorituskyvyn poistamiseksi.

Samanlainen asia on tehtävä solmun kanssa. Sinulla on tässä vaiheessa kaksi vaihtoehtoa:

  1. Suorita solmu klusteritilassa - klusteritila on arkkitehtuuri, joka tulee itse solmuun. Yksinkertaisesti sanottuna Node haarautuu useampaan omaan prosessiin ja jakaa kuorman yhden master-prosessin kautta.
  2. Suorita solmuprosessit itsenäisesti - Tämä vaihtoehto eroaa hieman edellisestä siinä mielessä, että sinulla ei ole nyt pääprosessia, joka ohjaisi alisolmuprosesseja. Tämä tarkoittaa, että kun teet eri solmuprosesseja, ne toimivat täysin toisistaan ​​riippumatta. Ei jaettua muistia, ei IPC: tä, ei viestintää, nada.

Stackoverflow-vastauksen mukaan jälkimmäinen (kohta 2) toimii huomattavasti paremmin kuin edellinen (kohta 1), mutta se on hieman temppu asennuksessa.

Miksi? Koska Node-sovelluksessa ei ole vain sovelluslogiikkaa, vaan melkein aina, kun asetat palvelimia Node-koodiin, sinun on sidottava portit. Ja yksi sovelluksen kooditieto ei voi sitoa samaa porttia kahdesti samalla käyttöjärjestelmällä.

Tämä ongelma on kuitenkin helposti korjattavissa. Ympäristömuuttujat, Docker-säilöt, NGiNX-käyttöliittymän välityspalvelin ja niin edelleen ovat joitain ratkaisuja tähän.

Rate Päätepisteiden rajoittaminen

Totta puhuen. Kaikilla maailmassa ei ole parhaita aikomuksia arkkitehtuurillesi. Toki, DDoS: n kaltaiset hyökkäykset ovat yksinkertaisesti hyvin monimutkaisia ​​lieventää, ja jopa GitHubin kaltaiset jättiläiset menevät alas, kun jotain sellaista tapahtuu.

Mutta vähiten mitä voit tehdä, on estää skripti-lasta poistamasta palvelinta vain siksi, että palvelimellasi on paljastettu kallis API-päätepiste ilman nopeudenrajoitusta.

Jos käytät Express with Node -sovellusta, on 2 kaunista pakettia, jotka toimivat saumattomasti yhdessä tason 7 liikenteen rajoittamiseksi:

  1. Express Rate Limit - //www.npmjs.com/package/express-rate-limit
  2. Express Slow Down - //www.npmjs.com/package/express-slow-down

Nopea hidastus lisää itse viivästyksen pyyntöihisi pudottamisen sijaan. Tällä tavoin laillisia käyttäjiä, jos he tekevät DDoS: n vahingossa (erittäin aktiivinen painikkeiden napsauttaminen täällä ja siellä), yksinkertaisesti hidastetaan eikä heitä ole rajoitettu.

Toisaalta, jos palvelimella on komentosarjoja, jotka suorittavat komentosarjoja palvelimen poistamiseksi, Express-nopeudenrajoitin valvoo ja nopeusrajoituksia tietylle käyttäjälle käyttäjän IP-osoitteesta, käyttäjätilistä tai mistä tahansa muusta haluamastasi.

Nopeudenrajoitusta voidaan (pitäisi!) Soveltaa myös kerrokseen 4 (kerros 4 tarkoittaa liikenteen estämistä ennen sen sisällön löytämistä - HTTP) IP-osoitteen kautta. Halutessasi voit asettaa NGiNX-säännön, joka estää liikenteen kerroksella 4 ja hylkää yhdeltä IP: ltä tulevan liikenteen tulon, mikä säästää palvelimen prosesseja ylivoimaisilta.

Käytä frontend-palvelinta SSL-yhteyden lopettamiseen

Solmu tukee heti SSL-kättelyjä selaimen kanssa käyttämällä httpspalvelinmoduulia ja tarvittavia SSL-varmenteita.

Mutta olkaamme tässä rehellisiä, sovelluksesi ei kuitenkaan pitäisi olla ensisijaisesti SSL: n alainen. Sovelluslogiikan ei pitäisi tehdä tätä. Solmukoodisi tulisi olla vastuussa vain pyynnön tapahtumista, ei palvelimesta tulevien ja sieltä tulevien tietojen esikäsittelystä ja jälkikäsittelystä.

SSL-päätteellä tarkoitetaan liikenteen muuntamista HTTPS: stä HTTP: ksi. Ja siihen on tarjolla paljon parempia työkaluja kuin Node. Suosittelen sille NGiNX: ää tai HAProxyä. Molemmilla on saatavana ilmaisia ​​versioita, jotka saavat työn valmiiksi ja purkavat SSL-päätteen solmusta.

Käytä staattisten tiedostojen palvelemiseen käyttöliittymäpalvelinta

Jälleen, sen sijaan, että käyttäisit sisäänrakennettuja menetelmiä, kuten express.staticstaattisten tiedostojen palvelemista, käytä staattisten tiedostojen levyltä palvelemiseen käänteisiä välityspalvelimia, kuten NGiNX.

Ensinnäkin, NGiNX voi tehdä sen nopeammin kuin Node (koska se on rakennettu alusta alkaen tekemään vain sitä). Mutta se purkaa myös tiedostopalvelun yksisäikeisestä solmuprosessista, joka voisi käyttää kellojaksojaan parempana.

Ei vain tämä - käyttöliittymän välityspalvelimet, kuten NGiNX, voivat myös auttaa toimittamaan sisältöä nopeammin GZIP-pakkauksen avulla. Voit myös asettaa vanhentumisotsikot, välimuistitiedot ja paljon muuta, mitä meidän ei pitäisi odottaa solmun tekevän (mutta solmu voi silti tehdä sen).

Määritä virheen käsittely

Oikea virheenkäsittely voi säästää tuntikausien virheenkorjauksesta ja vaikeiden virheiden toistamisesta. Palvelimella on erityisen helppo asettaa arkkitehtuuri virheenkäsittelyä varten, koska sinä suoritat sitä. Suosittelen työkaluja, kuten Sentry with Node, joka tallentaa, raportoi ja lähettää sinulle sähköpostia aina, kun palvelin kaatuu lähdekoodivirheen vuoksi.

Kun se on paikallaan, nyt on aika käynnistää palvelin uudelleen, kun se kaatuu, jotta koko sivusto ei vain mene alas tuntikausia, kunnes otat sen manuaalisesti.

Tätä varten voit käyttää prosessinhallintaa, kuten PM2. Tai vielä parempi, käytä telakoitua säiliöympäristöä käytäntöjen kanssa, kuten restart: alwaysoikean muistin ja levyn rajoitusten määritys.

Docker-asetukset varmistavat, että vaikka säilösi toimii OME: ssä, prosessi pyörii uudelleen (mikä ei ehkä tapahdu PM2-ympäristössä, koska käyttöjärjestelmä saattaa tappaa PM2: n, jos käynnissä olevassa prosessissa on muistivuoto).

Määritä lokit oikein

Kaikki vastaukset ovat lokissa. Palvelimen hakkerointi, palvelimen kaatuminen, epäilyttävä käyttäytyminen jne. Tätä varten sinun on varmistettava, että:

  1. Jokainen pyyntöyritys kirjataan siten, että IP-osoite / pyyntötapa / polku on käytettävissä, periaatteessa niin paljon tietoa kuin voit kirjata (paitsi yksityiset tiedot, kuten salasanat ja luottokorttitiedot, tietysti)
  2. Tämä voidaan saavuttaa morgan-pakkauksella
  3. Asennustiedostovirta kirjautuu tuotantoon konsolilähdön sijaan. Tämä on nopeampi, helpompi nähdä ja mahdollistaa lokien viemisen online-lokien katselupalveluihin.
  4. Kaikilla lokiviesteillä ei ole yhtä painoa. Jotkut lokit ovat vain virheenkorjausta varten, mutta jos joitain on läsnä, se saattaa viitata housuilla palotilanteeseen (kuten palvelimen hakkerointi tai luvaton käyttö). Käytä Winston-loggeria eri lokitasojen kirjaamiseen.
  5. Määritä lokin kierto niin, että et saa lokikokoa gigatavuina noin kuukauden kuluttua, kun näet palvelimen.
  6. GZIP lokitiedostosi kiertämisen jälkeen. Teksti on halpaa, erittäin kokoonpuristuvaa ja helppoa tallentaa. Sinun ei pitäisi koskaan kohdata ongelmia tekstilokien kanssa, kunhan ne on pakattu ja sinulla on palvelin, jolla on kunnollinen levytila ​​(25 Gt +).

Johtopäätös

Muutama tuotantokäytäntö on helppo ottaa huomioon, mikä voi säästää myöhemmin kyyneleitä ja useita tunteja virheenkorjausta. Varmista, että noudatat näitä parhaita käytäntöjä ja kerro minulle mielipiteesi sanomalla Hei twitter-kahvassani.

Jos pidit tästä artikkelista, tapaamme sosiaalisessa mediassa. Tässä on Instagram ja Twitter. Olen erittäin aktiivinen ja haluaisin keskustella! Yhdistetään.

Rauha!

Mehul