de Jared Nutt

Realitatea rulării unei aplicații Node de producție pe AWS Elastic Beanstalk

Lecții învățate de la 2 ani de rulare a unei aplicații Node de producție pe platforma ELS a AWS

Realitatea rularii unei aplicatii Node de productie pe AWS Elastic
Fotografie de Shane Rounce pe Unsplash

Front-Matter

Să fim sinceri, Calculator de prețuri AWS este confuz. O parte din aceasta se datorează a la carte metoda de plată oferită de AWS. Acest lucru face dificilă încercarea de a oferi un preț bun unui client. Sperăm că acest articol poate oferi o oarecare lumină cu privire la cât costă rularea unei aplicații, precum și câteva modalități de a reduce costurile.

Costul real al rulării unei aplicații

Gestionez o aplicație web nod pe ELB de aproximativ doi ani acum. Primul an a fost grozav, ți-au dat totul gratuit (mai ales)! După aceea, trebuie să începeți să plătiți pentru lucruri, cum ar fi instanțele EC2.

Acest articol se va concentra asupra cerințelor mele specifice de aplicație, care este o aplicație expresă bazată pe nod care este găzduită pe Elastic Beanstalk.

Pentru detalii complete despre versiune, consultați articolul meu anterior Aici.

Dărâma

Iată ce rulez în prezent pe AWS:

Mediu unic EBS (regiunea vestică SUA):

  • 1 Balansator clasic de încărcare
  • 1 instanță t2.micro EC2
  • S3 Bucket care conține imagini (7 GB în momentul scrierii)
  • 1 Ruta 53 Zonă găzduită

18 USD (Load Balancer) + 5 USD (EC2 cu un RI) + 0,50 USD (Traseul 53) + 0,17 USD (S3) + 0,21 USD (Transfer de date) = Aproximativ 25 USD o luna.

În plus, găzduiesc un MongoDB în altă parte, deci dacă intenționați să găzduiți un DB pe AWS, acesta va suporta costuri suplimentare. Să descompunem diferitele costuri.

Echilibrarea greutății

Aceasta este cea mai scumpă parte a stivei. Costă:

  • 0,025 USD per oră clasică de echilibrare a încărcării (sau oră parțială)
  • 0,008 USD per GB de date procesate de un Classic Load Balancer

Asta înseamnă că, dacă rulați aplicația 24 de ore pe zi, va costa aproximativ 18 USD + taxe pentru date, în fiecare lună.

Instanță EC2

Instanțele EC2 la cerere sunt mai scumpe decât ar trebui să fie. Pentru a economisi bani aici, consultați secțiunea de mai jos despre instanțele EC2 rezervate. În cazul în care vă întrebați, ar costa 8,40 USD pentru a rula același tip de instanță EC2 menționată mai sus, la cerere.

S3

Am câteva găleți S3. Una pentru pagina mea de pornire statică, una pentru păstrarea imaginilor și una pentru păstrarea versiunii aplicației. Din câte știu, ELB îl creează automat pe cel pentru gestionarea versiunilor aplicației.

S3 este destul de ieftin, așa că nu sunt prea îngrijorat de încercarea de a-l nichela și de a-l reduce, dar există modalități de a economisi bani prin intermediul lor Gheţar sistem.

Bază de date

Îmi găzduiesc DB-ul MongoDB la mLab, care va dispărea în curând. Așa că voi actualiza acest lucru atunci când voi afla cât va costa, de fapt, odată ce voi fi forțat să trec la Atlasul lui Mongo.

Instanțe EC2 rezervate

Să vorbim despre instanțe rezervate (RI). Sistemul complicat de facturare Amazon este partea cea mai confuză în ceea ce privește gestionarea a ceva pe AWS. Instanțele rezervate pot atenua o parte din costuri, dar sunt mult prea confuze.

După ce am citit și am vorbit mult cu serviciul pentru clienți AWS, asta mi-am dat seama.

În primul rând, există două moduri diferite în care puteți rezerva locul unde se află RI: Regional și Zone de disponibilitate. Mijloace regionale, este specific uneia dintre principalele regiuni, de ex. us-west-2 (Oregon). Zona de disponibilitate (AZ) este specifică unei zone din acea regiune, de exemplu, us-west-2A (Oregon).

Am cumpărat un RI în cadrul nostru-west-2 și a fost aplicat automat la instanța mea care rulează în acea zonă. Dacă cumpărați unul din AZ, acesta se va aplica doar AZ-ului specific, de exemplu, us-west-2a, deci dacă ELB creează o instanță EC2 în us-west2b, ​​nu aveți noroc.

În plus, există tipuri de RI „standard” și „convertibile”. Nu sunt 100% în ceea ce înseamnă asta, dar din ceea ce înțeleg convertibilul este mai flexibil în ceea ce îl puteți schimba, dar mai scump.

În cele din urmă, există trei tipuri de tipuri de plată: Nu în avans, parțial în avans, toate în avans. Acest lucru este destul de simplu, fie nu plătiți nimic, unele sau toate când rezervați instanța. Nu există niciun beneficiu de cost, pe care îl văd. Cu toate acestea, ca un cont nou, cel mai probabil nu puteți face niciun avans.

Per asistență AWS:

Fără instanțe rezervate în avans (RI) poate prezenta un risc semnificativ de facturare pentru conturile noi, deoarece acestea sunt o obligație contractuală de a plăti lunar pe întreaga durată a RI. Din acest motiv, conturile noi și conturile ușor folosite nu se pot înscrie pentru NR-uri inițiale până când nu se creează un istoric de facturare de succes cu noi.

S-ar putea să vă confruntați cu această eroare dacă încercați să cumpărați un avans în avans

Eroare: cota dvs. actuală nu vă permite să cumpărați numărul necesar de instanțe rezervate (Serviciu: AmazonEC2; Cod de stare: 400; Cod de eroare: ReservedInstancesLimitExceeded;)

Avertisment: indiferent de motiv, este nevoie de un pic pentru ca instanța rezervată să „dea start”, ceea ce înseamnă că prima zi a lunii costă întotdeauna mai mult. Nu sunt sigur de ce este acest lucru, dar dacă îmi dau seama, voi actualiza acest lucru. Vezi graficul de mai jos:

Realitatea rularii unei aplicatii Node de productie pe AWS Elastic

Puncte dureroase

Acestea sunt doar câteva reclamații minore cu privire la EBS-ul general, pe care am crezut că le voi include ca un addendum la articolul meu original, în cazul în care sunteți curios.

Actualizările automate nu sunt chiar atât de automate

Versiunile nodurilor nu se aliniază de la versiune la versiune.

Consultați pasul de mai jos despre cum gestionez schimbarea versiunilor Linux când Node nu funcționează.

Rularea mai multor medii

A avea un mediu de dezvoltare și o producție care rulează în același timp este ușor, dar este scump. De fapt, o dublează. Prin urmare, de obicei distrug mediul de dezvoltare imediat ce am terminat cu el.

Documentarea este oribilă

AWS este prea mare pentru binele său. De aceea scriu asta. A fost foarte greu să găsesc răspunsuri la nevoile mele specifice.

Cum gestionez actualizările

Am două instanțe separate de Git repo instalate pe laptop. Am unul pentru dev, și unul pentru producție.

Folosesc mediul de dezvoltare pentru a mă dezvolta! Destul de direct. Folosesc folderul de producție exclusiv în scopul extragerii actualizărilor din ramura principală Git, rularea configurației mele webpack și implementarea pe serverul de producție.

Motivul pentru care sunt separate este că pot să mențin configurații elastice separate de fasole și să nu-mi fac griji cu privire la implementarea în locul greșit.

Actualizări care nu necesită o modificare a mediului Linux

Pentru actualizările care nu necesită nicio modificare a mediului Linux, este la fel de simplu ca rularea eb deploy în terminal. Este uimitor și durează aproximativ 10 minute să se propagă.

Actualizări care necesită o modificare a mediului Linux

Ocazional, veți dori să actualizați mediul Linux, dar nu veți putea, de asemenea, pentru că AWS este nebun (sunt sigur că există un motiv) și permite doar anumite versiuni de nod pe fiecare versiune Linux. Pentru aceasta, este puțin mai complicat, dar ușor de gestionat.

  1. Treceți la configurația de producție sub noua inv. Ultima dată când am făcut acest lucru, tocmai am creat o nouă instanță prin eb create prod-1 . Va face ceea ce trebuie și va implementa aplicația dvs. într-un mediu nou.
  2. Asigurați-vă că toate actualizările dvs. funcționează. Pare destul de evident, dar acesta este un moment bun pentru a ne asigura că nu au existat sughițuri cu noua versiune.
  3. Asigurați-vă că vars-urile dvs. de env sunt configurate corect. Aceasta face parte din versiunea anterioară, dar asigurați-vă că trageți din DB-ul potrivit sau orice altceva.
  4. Asigurați-vă că balansatorul de încărcare are același certificat SSL (dacă este cazul). Fapt amuzant, dacă încercați să accesați o instanță ELB în https fără certificat, va eșua!
  5. Schimbați instanțele. În cele din urmă, după ce totul arată bine, există un buton în consolă pentru a schimba adresele URL de instanță. EASY PEASY. Nu trebuie să schimbi nimic în Traseul 53, face totul pentru tine.

Deci, iată-l. Cum să vă gestionați actualizările. Destul de ușor.

Gânduri finale

Dacă aveți sugestii pentru ao face mai ieftin / mai ușor, mi-ar plăcea să le aud. Îmi place discuția despre instrumente și opțiuni la fel de mult ca și următorul dezvoltator!

Cu asta, voi pleca cu asta: Codificare fericită!