“Zone taltsutab püütonit” ehk oluline teave Pythoni kasutajatele

1. novembril kaob Zone platvormist võimalus kasutada programmeerimiskeele Python VANU versioone. Alles jääb tugi värskeimale Pythoni versioonile. Muutuse põhjuseks on Pythoni keeruline ühilduvuspoliitika ning vanematest versioonidest tulenev risk meie serveriplatvormi stabiilsusele ja turvalisusele. Python on maailma üks polulaarseimaid programmeerimiskeeli, mistõttu selle toe päriselt kaotamist me ei kaalu.

Kurioossel kombel viib see meid varasemast selgemini ühele joonele Pythoni disainifilosoofiaga milleks on: “asjade tegemiseks peaks olema üks – ja soovitavalt ainult üks – ilmne viis”.

Silly Python

Zone virtuaalserveri ja nutika pilve-privaatserveri klientide enamus ootab teenuselt eelkõige toimivat klassikalist LAMP (Linux + Apache + MySQL + PHP) tarkvarakomplekti. Nii oli see 20 aastat tagasi ja nii on see ka praegu. Alati pole aga sellest piisanud ning seetõttu oleme aja jooksul lisanud platvormi uusi tarkvaratükke, mida ka LAMP rakendused kasutada soovivad. Lisamise tingimuseks on piisav kasutajate hulk ja mõistliku uuendamise võimalus.

Nii on näiteks platvormi lisandunud:

* Redis (hoiame viimast stabiilset versiooni)

* Node.js (hoiame viimast LTS versiooni)

Valdava osa ajast on meie platvormis olemas olnud ka programmeerimiskeel Python. Kuna tegemist on maailma populaarseima programeerimiskeelega, siis teisiti ei saakski ja Pythonit kasutab ka Zone ise.

Populaarsus tingib ka klientide huvi, kuid Pythoni ühilduvuspoliitika ning olemus teevad selle toetamise Zone platvormis väga keeruliseks. Sellist tuge, nagu näiteks PHP-le, me pakkuda ei saa ning me ei soovita Zone virtuaalserveris jooksutada suuri Pythoni rakendusi. Ad-hoc, analüüsi jms mitte kriitiliste rakenduste käivitamiseks on Python aga sobiv.

Korduvate küsimuste ning segaduste vältimiseks proovime võtta järgnevalt kokku selle, mida Zone pakkuda saab ja ei saa.

Mida me lubada SAAME:

* Kuigi mitte alati kõige viimast, siis mõistlikult värsket Pythoni versiooni süsteemis (hetkel on selleks versiooniks 3.8). Paralleelselt mitut versiooni hoiame süsteemis ainult üleminekuajal.

* Mooduleid virtuaalkeskkondade loomiseks (pip jms). Virtuaalkeskkonnad on ka ainuõige viis Zone platvormis Pythoni rakenduste kasutamiseks.

* Mysqlclient moodulit MySQL/MariaDB andmebaasidega suhtlemiseks.

Mida me pakkuda EI SAA:

* Paralleelselt erinevaid Pythoni versioone.

Nimelt vajab Python tööks tihti palju rohkemaid mooduleid, kui nt PHP, kuid arendajate soovimatus stabiilset API-t, sõltuvusi jms hoida teeb paralleelselt mitme Pythoni versiooni platvormis hoidmise äärmiselt keeruliseks. Paralleelselt mitut versiooni hoiame süsteemis ainult üleminekuajal, et anda sellega klientidele võimalus virtuaalkeskkonnad uuemale versioonile üle viia.

* Võimalust mooduleid kompileerida.

Zone platvorm on oma olemuselt “rolling distro” ja iga uuendus võib muuta või eemaldada teeke, mille vastu Pythoni moodulid ennast linkida võivad.

* Tuge Pythoni rakendustele, nende migreerimiseks uuemale Pythoni versioonile jne.

Ajaloolistel põhjustel on hetkel platvormis isegi kolm Pythoni versiooni – 2.7, 3.6 ja 3.8. Tugi versioonile 2.7 on juba lõppenud ning versiooni 3.6 tugi lõppeb selle aastaga ning nüüd on aeg need vananenud versioonid platvormist eemaldada.

Pane nüüd tähele: alates 1. novembrist tehtavad uuendused eemaldavad meie platvormist Pythoni versioonid 2.7 ja 3.6, misjärel jääb alles ainult versioon 3.8!

Palume selle aja jooksul oma virtuaalkeskkonnad ja skriptid kindlasti versioonile 3.8 üle viia.

Täiustame veebiserverite logimist

Järgnev postitus on suunatud klientidele ning neid esindavatele tehnilistele võluritele, kes veebiserverite logisid aktiivselt jälgivad ning analüüsivad.

Nimelt on Zone parandamas oma veebimajutuse logide vormistuse ja säilitamise korda ning 27. septembrist plaanime sellele üle minna kogu oma ZoneOS platvormi ulatuses. See hõlmab muuhulgas ka kõiki meie Virtuaalserveri teenuseid.

Aga haarakem härjal sarvist. Täna on meie veebiserveri logides kirjed vormistatud selliselt:

example.com 1.2.3.4 - - [08/Mar/2021:13:58:23 +0000] "GET / HTTP/1.0" 200 3390 "https://example.com/referer" "ApacheBench/2.3" (064FD630-5.001)

Koosneb see logirida järgmisest infost:

  1. veebileht, millele päring tehti
  2. IP aadress, millelt päring tehti
  3. esimene “-” on pärand ajaloo hämarustest, mil veebiserver sai ’identd’ teenuse kaudu pärija arvutist teada päringu teinud külastaja nime, tänapäeval pole see võimalik ja see väli on alati tühi
  4. teine “-” kuvatakse päringust puuduva kasutajanime asemel, HTTP Basic Authentication kasutamisel seisab siin kasutajanimi
  5. päringu kuupäev ja kellaaeg
  6. päringu sisu (antud juhul siis teostati vanamoelisele HTTP/1.0 standardile vastav GET päring veebilehe juurkataloogi pihta)
  7. päringu vastuse kood, 200 tähendab OK
  8. päringu vastuse suurus
  9. lehekülg, mis viitas päritud lehele (kui see info pandi brauseri poolt kaasa)
  10. veebilehitseja, mis päringu teostas, meie näite puhul kasutati selleks ApacheBench nimelist käsureautiliiti
  11. Zone poolt arendatava ja kasutatava PHP-ZFPM mooduli poolt päringule antud identifikaator, mis võimaldab meil probleeme lahendada

Uus logikirje vorm näeb välja selline:

example.com 2021-03-08T13:58:23.209048Z 1.2.3.4 12345 - - "GET / HTTP/1.0" 200 3390 "https://example.com/referer" "ApacheBench/2.3" 1621846 (064FD630-5.001)

Tähele tasub panna järgmist:

* päringu aeg on kolinud rea 5. positsioonilt 2. positsioonile
* päringu aeg antakse nüüd edasi mikrosekundites (RFC3339 standardile vastavalt), sest meie veebiserverid on nii kiired, et sekund on päringute analüüsimiseks liiga pikk ajaühik 🙂
* päringu aja ümbert on eemaldatud nurksulud, et seda oleks lihtsam töödelda
* päringu aeg on nüüd kahe stringi asemel üks string, mis teeb selle samuti lihtsamini töödeldavaks
* lisaks päringu lähteaadressile (3. positsioon) logitakse nüüd 4. positsioonil ka lähteport, et NAT teenuse taha sattunud kasutajate probleemide lahendamine oleks lihtsam
* ühtlasi leiab eelviimaselt positsioonilt info selle kohta, kaua (seinakella järgi) läks veebiserveril aega päringule vastamiseks, taas mikrosekundites

Logide säilitamise korras on samuti toimumas muutused, mis puudutavad peamiselt veebiserveri ja PHP logifailide nimesid ja on osaliselt juba jõustunud:

* kui seni sisaldas logifaili nimekiri järjekorranumbrit (apache.ssl.access.log.1.gz), siis nüüd sisaldab see kuupäeva (apache.ssl.access.log.2021-09-16.gz)
* kui samal kuupäeval tekib mitu arhiivifaili, siis pannakse igale järgnevale failile kuupäeva taha järjekorranumber, alustades 1-st.

Muutus failinimedes aitab meil klientidele kokku hoida varukoopiate ruumi, kuna see vähendab varukoopia tegemisel muutunuks loetavate failide hulka.

Kardetavasti on isegi meie blogi lugejatest 99% inimesi juba vajutanud back nuppu, sest “who cares”, aga logid on meie töös äärmiselt tähtsad. Seetõttu kui ülalolevast infost oli sulle ka sinu töös kasu, siis meie poolt “respect“!

18.01.2021 katkestuse post-mortem

Esmaspäeva, 18. jaanuari õhtul lõpetas töö üks meie võrguseade, täpsemalt kommutaator ehk switch, mille kaudu käib mitmete serverite võrguühendus.

Tegemist oli seadmega, milles riskialtid komponendid dubleeritud, kuid mille riknemisi siiski esineb. Tavapäraselt oleme võrguseadme väljavahetamise ajakuluks arvestanud umbes 1 tunni. Selliste seadmete korralise väljavahetamise tsükkel on meil 5 aastat, uued täielikult dubleeritud seadmed olid seadistamise lõppfaasis.

Katkestus algas kell 17:15 ja mõjutas ca 40% Virtuaalserveritest ning 1/3 tavapärasest veebipäringute arvust. Klientide muud teenused nagu e-post, nimeserverid, ZoneCloud toimisid normaalselt.

Paraku ilmnes võrguseadme vahetamise järel, et tavapärase liiklusmahu korral kahaneb võrgukiirus olematuks.

Järgnes veaotsing, mille käigus prooviti läbi erinevad vea-hüpoteesid, paigaldati järgmine varuseade ja valmistuti ka võrgusegmendi üleviimiseks erinevale tehnoloogiale. Lõpuks tuvastati probleemina kommutaatori tarkvara viga, mis ilmnes reaalse koormuse tekkimisel ning mida ei olnud võimalik testkeskkonnas tuvastada. Probleemi lahendas vanema tarkvaraversiooni kasutuselevõtt, kõigi teenuste töö oli lõplikult taastunud kella 00:50ks.

Mida me teeme teenuste tõrkekindluse parandamiseks?

Kuna kõik Virtuaalservereid teenindavad serverid on meil test-rakenduse tasemel välises monitooringus jälgitavad, siis teame, et nende käideldavusnäitaja, milles sisalduvad ka korralised hooldused, on aasta lõikes 99,96-99,98%. Käesoleva katkestuse järel on mõjutatud serverite aastane näitaja tasemel 99,85%-99,89%. Meie eesmärk on alati olnud hoida oma teenustase koos hooldusakende arvestusega üle 99,9% käideldavusel ja hooldusaknaid välja jättes võimalikult lähedal 100%-le.

Nagu mainitud oli meil ettevalmistamisel võrguseadmete väljavahetamine ja täielik dubleerimine eesmärgiga selliseid riske maandada. Viime selle lõpuni lähinädalatel ja mõistagi öisel ajal, täpsest ajast teavitame kliente e-kirjaga.

Palume vabandust rikke põhjustatud ebamugavuste pärast ja panustame aastal 2021 veelgi enam sellesse, et kõik Zone teenused oleksid võrdselt töökindlad, ajaga kaasas käivad ja turvalised.

Ja kindlasti tänud neile, kes meie tehnikute tegevusele sotsiaalmeedias kaasa elasid – püüame olla oma tegevustes võimalikult läbipaistvad, kuvades nii tõrkeid kui plaanitud hooldusi zone.ee esilehel koos viitega status.zone.eu lehele, kust huvilistel on võimalik tellida ka teavitused e-postile. Samuti võite alati kindlad olla, et Zone süsteemid on 24/7/365 monitooritud ning sõltumata nädalapäevast või kellaajast ning riketega tegeletakse, kuni need on lõplikult lahendatud.

Tehniline taust

Tegemist oli võrgusegmendiga, kus oleme viis aastat kasutanud SDN (Software Defined Networking ehk programmeeritav võrgustus) tehnoloogiat, mis lahutab võrgu riistvara ja tarkvara üksteisest sõltumatumaks. Lihtsustades tähendab see, et kasutame Linuxil põhinevaid võrguseadmeid maailma juhtivatelt tootjatelt, mis on oma iseloomult suhteliselt lihtsad ja robustsed meie spetsialistidele seadistada, hallata jne.

Samuti on meil korraliste riistvarauuenduste käigus võimalik valida parim lahendus, olemata seotud ühe tarnijaga. Nagu eespool mainitud, olime ühte sellist vahetust just ette valmistamas, uued seadmekapid olid ette valmistatud ning lähinädalatel plaanis serverite üleviimine. Tavapäraselt olid nii põhi- kui varuseadmed seadistatud kasutama tarkvara värskeimat stabiilset versiooni ning testitud.

Üks selline varuseade võeti kasutusele ning alglaadimise järel tundus kõik andmekeskuses olevatele tehnikutele toimivat, aga kaughaldust tegeval meeskonnal oli probleeme ligipääsuga serveritele. ping toimis kenasti, aga ssh oli probleemne, staatiline sait HTTP peal toimis aga HTTPS keeldus kätlemast, andmebaasiserveriga ei saadud ühendust jne.

Kogu võrguseadmete konfiguratsioon käidi ridahaaval läbi, et tuvastada erisusi kõrval töötavate seadmetega. Katsetati kõiki võimatuid ja võimalikke riistvaraga seotud teooriaid alates AOC (Active Optical Cable) kaabliriketest, lõpetades võimalike anomaaliateni DDoS kaitses jne.

Vea tuvastamise protsessi käigus toodi meie teisest andmekeskusest kohale kolmas sarnane võrguseade välistamaks võimalust, et esimene asendusseade on vigane. Jällegi, läbiti tavapärane protseduur selle seadistamiseks ja paigaldamiseks, kuid kahjuks jõuti kõikide muudatuste tulemusena täpselt samasse punkti välja. Kõik töötab, aga seadmesse sisenedes kahaneb andmeside olematuks – nagu autol rakenduks puhtal sirgel teel veojõukontoll.

Lõpuks jõudsime tegeliku juurprobleemini. Mis nii kurioosne kui see ei ole, oli seotud selle võrguseadme eesootava asendusega. Nagu öeldud, siis SDN puhul on tihti kasutusel arhitektuur, kus võrgu riistvara on ühelt tootjalt (nö “white box”) ja selle nutikus tuleb Linux operatsioonil põhineva tarkuse kaudu mujalt. Selgus, et meie tehnikud kasutasid rikkis võrguseadmele asenduse paigaldamisel Linuxi versiooni, mida nad olid juba kasutanud uute võrguseadmete ettevalmistamisel. See oli aga mõne väljalaske võrra uuem, kui see mis varasemasse seadmesse oli paigaldatud. Uus tarkvaraversioon sisaldas seni täpselt tuvastamata viga ning probleem lahenes vanema tarkvaraversiooni paigaldamisega.

Järgmisel päeval suutsid tehnikud laboritingimustes probleemi reprodutseerida. Me ei tea veel milline tarkvara “bugi” või ”uus featuur” täpselt seda põhjustas, aga ASIC erikiipidel toimuv superkiire TCP/IP pakettide edastamine lülitati seadmes välja ja nende edastamine läks üle CPU-le ehk protsessorile, mis andmeside kontekstis on võrgu jõudlusele sisuliselt surmahoop. Paraku ei täheldanud me sedapuhku ka CPU koormusnäitajate märkimisväärset tõusu. Nimelt on selles samas tarkvaras ka loogika, mis piirab protsessorile edastatavate pakettide arvu ülekoormust ennetavalt ära.

Takkajärgi sündmuste ahelat läbi vaadates tundub kõik muidugi lihtne, aga reaal-ajas tähendas see paljudele seda, et esmaspäeval tuli tööpäevale teine ja keskmisest stressirohkem otsa. Tegutseme edasi selle nimel, et 24/7/365 käideldavus oleks saavutatav rahulikult 9st 17ni riske maandades :.)

Amsterdamis majutatud serverid kolivad uude andmekeskusesse

Neljapäeva, 26. jaanuari varahommikul kolime Amsterdamis majutatud Pilve- ja Virtuaalserverid uude andmekeskusesse.

Kolimisega kaasneb katkestus kell 01-05 (Eesti aja järgi), kliendid keda see mõjutab said nädal tagasi e-postile ka vastava eelteavituse.

Kuna meie seni kasutatud Amsterdami andmekeskus hakkas kitsaks jääma, oleme umbes pool aastat plaaninud oma serverite kolimist uude andmekeskusesse.

Toide, võrguühendused ning osa võrguseadmetest on seal juba kohal ja testitud, 26. jaanuari varahommikul liiguvad ühest majast teise ka serverid, mida kasutavad Pilveserver PRO SSD kliendid, aga samuti oma asukohaks Amsterdami valinud Pilveserver VPS ja Virutaalserverite kliendid.

Kolimisega kaasneb ca 4h katkestus – aga nagu timelapse-videost näha, oleme me seda juba oluliselt suurema hulga serveritega harjutanud:

Zone teenuste olekut saab reaalajas jälgida status.zone.eu, samast saab ka tellida e-postile teavituse intsidentide kohta.

Uus asukoht Euroopa ühes kaasaegsemas andmekeskuses (Equinix AM6) tõstab meie süsteemide töökindlust, tagades kõrgendatud nõuetele vastavad toite- ja võrgulahendused, võimsama kliimatehnika ja kõrgema turvalisuse. Andmekeskuse sertifitseeringud hõlmavad nii ISAE 3402, ISO27001, ISO 140001, ISO 50001 kui ka PCI DSS standardeid. Mitmekordistub ka meie kohapealse andmesidevõrgu ühenduskiirus.

Kuna uues andmekeskuses avaneb meil võimalus paindlikumalt muuta olemasolevaid ning luua uusi teenuseid, siis oleme huvitatud ka teie ettepanekutest, soovidest ja tagasisidest – muuhulgas on uues kohas juba paigas esimesed Nutikad Privaatserverid.

Node.js veebirakendused nüüd Zone virtuaalserveris – kauba peale PM2, mod_proxy ja portide suunamine

Võimalus käsurealt Node.js rakenduste käivitamiseks tekkis Zone virtuaalserverites umbes aasta tagasi koos SSH-ligipääsu lubamisega – aga kuna kogu veebiliikluse võttis enda peale Apache, puudus võimalus neile internetist ligi pääseda. Ekstreemsemad kasutajad aga leidsid omal käel lahendusi – passiivse FTP jaoks on mingi pordivahemik ikkagi avatud, mod_proxy abil saab liiklust suunata ja cron’i saab panna skripti, mis tagab rakenduse käigushoidmise. Katsetamiseks “intellektuaalselt huvitav nipp”, aga selle abil kaugele ei purjeta.

Kui aga hakkasime kasutajate huvist tulenevalt Node.js veebirakenduste jaoks head lahendust otsima – algselt plaanitud kiire nädalavahetuse-häkatonina – jõudsime oluliselt laiemat kasutust omavate komponentideni virtuaalserveri halduses:

  • Erinevate rakenduste seadistamise ja serveri restardil automaatse käivitamise võimalus (seda kasutab juba meie Redis-vahemälu lahendus.)
  • PM2 protsessihaldur, mille abil saab käivitada ja hallata Node.js rakendusi (aga ka näiteks PHP või shelli skripte).
  • Apache mod_proxy seadistus, mis võimaldab suunata veebiliikluse (ehk port 80 ja HTTPS puhul ka 443) kasutaja rakenduse poolt kuulatavasse porti.
  • Portide suunamine (port forwarding), mis võimaldab virtuaalserverile eraldatud IP kasutamisel avada ja suunata väliseid porte (>1024) ja sobib mh WebSocket’it implementeerivate rakenduste jaoks.

Kuidas seda kõike kohe omal nahal järgi proovida?

Sellest videost leiab “Hello world” rakenduse käivitamise näite – keerulisemad juhud nagu tuntumate raamistike kasutamine, Websockets’i tugi jms saavad oma videoõpetused veidi hiljem.

Meetod 1 – mod_proxy

Alustaks ühest väga lihtsast Node.js “Hello World!” rakendusest – teen testimise tarbeks virtuaalserveri halduses uue alamdomeeni node.miljonivaade.eu ja määran sinna lisandunud parameetri mod_proxy sihtpordi väärtuseks 8080. Selle tulemusel hakkab Apache toimima reverse proxy‘na ehk kõik porti 80 tulevad HTTP päringud suunatakse edasi localhost’i porti 8080.

node-subdomain-dip

Kui domeenil või alamdomeenil on lubatud ka HTTPS, saab selle seadistada samamoodi (või kasutada HTTP seadeid) – seejuures on oluline arvestada, et nagu reverse proxy puhul sageli tavaks, toimub turvaline SSL ühendus kasutaja ja Apache vahel, sealt edasi Node.js rakenduseni liigub lahtine HTTP päring.

Seejärel laen üles app.js koodi (asukohaks ei pea olema alamdomeeni kodukataloog):

var http = require("http");

http.createServer(function (request, response) {
 response.writeHead(200, {'Content-Type': 'text/plain'});
 response.end('Hello World! I am a Node.js app :-)\n');
}).listen(8080);

Nagu näha, tekitab see porti 8080 kuulava veebiserveri ning tagamaks selle käivitamise ka pärast tõrget või füüsilise serveri restarti, on vaja see lisada PM2 protsessihaldurisse (Veebiserver › Node.js ja PM2):

node-add-app

Rakendusi saab lisada nii .js kui PM2 rakenduse deklaratsiooni .json või .yml failina, mis lubab seadistada kõiki PM2 parameetreid, käivitada korraga mitut rakendust jpm.

Kasutada olev summaarne mälukogus sõltub virtuaalserveri paketist ning seda saab jagada mitme rakenduse vahel omal äranägemisel.

Protsessi lisamise järel võib minna kuni 3 minutit selle tegeliku käivitumiseni, olekut näeb lehe uuestilaadimisel (tulevikus loodetavasti ka ilma laadimiseta). Ja kui see on “Käivitatud”, siis võib testima asuda:

hello-there

Edaspidi saab rakendust samast kohast virtuaalserveri halduses peatada, muuta, kustutada ja restartida.

Meetod 2 – port forwarding

Selle lihtsa mod_proxy lahenduse puhul ei toimi aga WebSocket ühendused, nende jaoks oleks vaja kogu välisesse porti tulev liiklus rakendusele suunata.

Selleks lisasime virtuaalserveri haldusesse pordi suunamise võimaluse – tõsi, selle kasutamiseks on vaja eraldi IP-aadressi, mida pakub Pakett III (üks aadress sisaldub hinnas, selle aktiveerimiseks tuleb saata kiri klienditoele). Olgu siinkohal mainitud, et portide suunamine kasutamine torrenti- või mänguserveri, proxy vms teenuse jaoks on rangelt keelatud seoses võimalike juriidiliste ja serveri koormuse küsimustega. Kui kahtled plaanitava kasutuse lubatavuses, siis kirjuta palun meie kasutajatoele ning kirjelda oma rakendust ja eeldatavat kasutajate hulka.

Demoks sobib kenasti socket.io näidis-chat, mille paigaldan serveris vabalt valitud asukohta, tehes SSH abil vajalikud npm install’id ja seadistan seejärel PM2 abil käivitatavaks:

node-app-list

Kui nüüd ülevalpool olevat alamdomeeni seadistust uuesti vaadata, hakkab loodetavasti silma, et seal on alamdomeenile eraldi IP-aadress juba määratud (217.146.71.171) ning mul pole vaja teha muud, kui lisada vastav pordi suunamine näidis-chatis kasutusel oleva port 3000 jaoks:

node-port-forward

Pordi suunamise rakendumine võib aega võtta kuni 10 minutit. Selle ajaga jõuab teha väikse kohvipausi ja minnes seejärel aadressile node.miljonivaade.eu:3000 … on tulemuseks toimiv chat:

weirdo-chat

Mis edasi?

Edasi võiks proovida näiteks rakenduse käivitamist mitte .js, vaid .json abil – kui lisada sama “Hello, World” rakenduse kataloogi selline app.json, muuta vastavalt PM2 seadistuses rakenduse asukoht ja see taaskäivitada …

{
 "apps" : [{
 "name" : "hello-world",
 "script" : "app.js",
 "watch" : true,
 "cwd" : "/data02/virt33390/domeenid/www.miljonivaade.eu/nodetest",
 }]
}

… siis hakkab PM2 jälgima parameeteriga cwd määratud kataloogis toimuvaid failimuutusi ja restardib rakenduse automaatselt. Mugav harjutamise või arenduse käigus, aga ilmselt tasuks production’is mitte peale unustada. Samuti “te ei usu, mis juhtub”, kui watch’iga rakendus midagi ise enda kataloogi kirjutab, näiteks logifaili: rakendus ‘retarditakse’ ehk PM2 proovib kümmekond korda restartida ja loeb siis asja lootusetuks.

Kui PM2 käivitusprotsessis miski nihu läheb – või on soov katsetada ilma virtuaalserveri haldust mängu segamata – siis saab sellele ligi ka SSH abil. Olulisemad käsud leiab PM2 spikrist, samas on kirjas ka kataloogistruktuur, mille PM2 tekitab virtuaalserveri kodukataloogi alla (sealt leiab nii rakenduste kui PM2 logid).

pm2-list

Ja kuna PM2 on tehtud Keymetrics’i poolt … siis saab ühe käsuga lisada ka nende monitooringu (lihtsam vaade tasuta, paremad tööriistad ja teavitused raha eest):

pm2-keymetrics

Ja edasi edasi?

Uuri, proovi, katseta – ilmselt on paslik seda lahendust hetkel beetaks lugeda ning anda meile teada sellest, mis ei toimi oodatud viisil, vajaks muutmist või lisamist. Või siis mis toimib väga hästi ja lahendab tegelikke probleeme 🙂

Teada võib anda otse siinsamas kommentaari-sabas, meie FB-lehel, kirjutades peeter@zone.ee või liitudes meie slack.zone.eu kanaliga.

Korduma Kippuvad Küsimused

Mis Node.js versiooni kasutate? Hetkel on selleks 6.3.0, edaspidi hakkame hoidma kõiki servereid värskeima LTS peal.

Palju mälu kasutada saab? Sõltub paketist – I, II ja III vastavalt 512MB, 768MB ja 1024MB. Mälupiir on hetkel soft limit ehk toimub “proaktiivne monitooring” ja piiritundetud kasutajad kutsutakse küberneetiliselt korrale.

Ma saan selle PM2 ju ise kah SSHs käima tõmmata? Tõsi, aga siis ei ole tagatud rakenduste taaskäivitumine serveri restardi puhul.

Miks te PM2 valisite, xyz on palju parem? Sellepärast, et.

Kas Node.js binaarsed moodulid ei olegi toetatud? Kuna oleme otsustanud kompilaatoreid virtuaalserverites mitte pakkuda, puudub ka võimalus binaarseid mooduleid paigaldamise käigus kompileerida. Meie hinnangul saab suurem osa Node.js rakendustest ilma hakkama.

Rohkem küsimusi ei ole? Hakkame siis tööle!
(kui on küsimusi – võid liituda Skype grupi-chatiga)