Stvarnost pokretanja produkcijske aplikacije Node na AWS Elastic Beanstalk

Lekcije naučene iz 2 godine rada proizvodne Node aplikacije na AWS ELB platformi

Prednja stvar

Budimo iskreni, kalkulator cijena AWS zbunjuje. Dio toga je i a la carte način plaćanja koji AWS nudi. To otežava pokušaj davanja dobrog citata klijentu. Nadamo se da ovaj članak može pružiti malo svjetla o tome koliko košta pokretanje aplikacije, kao i neke načine za smanjenje troškova.

Stvarni trošak pokretanja aplikacije

Već oko dvije godine upravljam web-aplikacijom čvora na ELB-u. Prva godina je bila super, dali su vam sve besplatno (uglavnom)! Nakon toga morate početi plaćati stvari, poput EC2 slučajeva.

Ovaj će se članak usredotočiti na moje specifične zahtjeve aplikacije, a to je ekspresna aplikacija zasnovana na čvorovima koja je hostirana na Elastic Beanstalk-u.

Za sve detalje o izradi pogledajte moj prethodni članak ovdje.

Slom

Ovo je ono što trenutno radim na AWS-u:

Jedno EBS okruženje (zapadna regija SAD-a):

  • 1 Klasični uravnoteživač tereta
  • 1 t2.micro EC2 instanca
  • S3 kanta koja sadrži slike (7 GB u vrijeme pisanja)
  • 1 Ruta 53 Hostirana zona

18 USD (Load Balancer) + 5 USD (EC2 s RI) + 0,50 USD (ruta 53) + 0,17 USD (S3) + 0,21 USD (Prijenos podataka) = Otprilike 25 USD mjesečno.

Uz to, MongoDB hostiram negdje drugdje, pa ako planirate hosting DB-a na AWS-u, to će imati dodatnih troškova. Razdvojimo razne troškove.

Balanser opterećenja

Ovo je najskuplji dio hrpe. To košta:

  • 0,025 USD po satu klasičnog uravnoteživača opterećenja (ili djelomičnog sata)
  • 0,008 USD po GB podataka koje obrađuje Classic Load Balancer

To znači da ako aplikaciju upotrebljavate 24 sata dnevno, koštat će približno 18 USD + podatkovni troškovi svaki mjesec.

Instanca EC2

Primjeri EC2 na zahtjev skuplji su nego što bi trebali biti. Da biste ovdje uštedjeli novac, pogledajte odjeljak u nastavku o rezerviranim primjercima EC2. U slučaju da se pitate, pokretanje iste vrste EC2 instance kao što je gore spomenuto koštalo bi 8,40 USD na zahtjev.

S3

Imam nekoliko kanta S3. Jedan za moju statičnu početnu stranicu, jedan za držanje slika i jedan za držanje verzije aplikacije. Koliko znam, ELB automatski stvara onu za upravljanje verzijama aplikacija.

S3 je prilično jeftin, tako da nisam previše zabrinut zbog pokušaja nikliranja, ali postoje načini za uštedu novca putem njihovog Glacier sustava.

Baza podataka

Hostiram svoj MongoDB DB na mLab, koji uskoro odlazi. Dakle, ažurirat ću ovo kad sredim koliko će to zapravo koštati kad budem prisiljen preseliti se u Mongov Atlas.

Rezervirani primjerci EC2

Razgovarajmo o rezerviranim primjercima (RI). Amazonov zamršeni sustav naplate zbunjujući je dio upravljanja bilo čime na AWS-u. Rezervirani slučajevi mogu ublažiti neke troškove, ali su previše zbunjujući.

Nakon puno čitanja i razgovora s korisničkom službom AWS-a, ovo sam nekako shvatio.

Prvo, postoje dva različita načina na koja možete rezervirati gdje je RI: Regionalna i zona dostupnosti. Regionalno znači, specifično je za jednu od glavnih regija, npr. us-zapad-2 (Oregon). Zona dostupnosti (AZ) specifična je za zonu unutar te regije, npr. Us-zapad-2 a (Oregon).

Kupio sam RI unutar us-west-2 i automatski je primijenjen na moju instancu koja radi u tom području. Ako kupite jedan unutar AZ-a, to će se odnositi samo na određeni AZ, npr. Us-west-2a, pa ako ELB zavrti EC2 instancu u us-west2b, ​​nemate sreće.

Pored toga, postoje „standardni“ i „kabriolet“ tipovi RI-a. Nisam 100% siguran što to znači, ali prema onome što razumijem, kabriolet je fleksibilniji od onoga na što ga možete zamijeniti, ali skuplji.

Napokon, postoje tri vrste plaćanja: Nema unaprijed, djelomično naprijed, sve naprijed. Ovo je prilično jednostavno, ili nećete platiti ništa, neke ili sve kada rezervirate instancu. Ne vidim troškovnu korist, koliko vidim. Međutim, kao novi račun najvjerojatnije ne možete ništa unaprijed napraviti.

Po AWS podršci:

Nijedna unaprijed rezervirana instanca (RI) ne može predstavljati značajan rizik naplate za nove račune, jer su oni ugovorna obveza mjesečnog plaćanja za cijeli rok RI-a. Iz tog razloga novi računi i slabo korišteni računi ne mogu se prijaviti za nikakve unaprijed RI-je dok se s nama ne izgradi uspješna povijest naplate.

Možete pokušati naletjeti na ovu pogrešku ako pokušate kupiti ne-up.

Pogreška: Vaša trenutna kvota ne omogućuje vam kupnju potrebnog broja rezerviranih primjeraka (usluga: AmazonEC2; statusni kôd: 400; kôd pogreške: ReservedInscationsLimitExceeded;)

Napomena: Iz bilo kojeg razloga, potrebno je malo da rezervirana instanca "upali", što znači da prvi dan u mjesecu uvijek košta više. Nisam siguran zašto je to tako, ali ako shvatim, ažurirat ću ovo. Pogledajte grafikon u nastavku:

Točke bola

Ovo su samo neke manje pritužbe na cjelokupni EBS, za koje sam pretpostavio da bih ih uključio kao dodatak svom izvornom članku, u slučaju da ste znatiželjni.

Automatska ažuriranja zapravo nisu toliko automatska

Verzije čvorova ne poravnavaju se od verzije do verzije.

Pogledajte donji korak o tome kako upravljam promjenom inačica Linuxa kada Node ne radi.

Pokretanje više od jednog okruženja

Imati razvojno okruženje i istovremeno raditi proizvodnju lako je, ali je skupo. Zapravo to udvostručuje. Stoga obično uništavam razvojno okruženje čim završim s njim.

Dokumentacija je užasna

AWS je prevelik za svoje dobro. To je dio zašto ovo pišem. Bilo je stvarno teško pronaći odgovore na moje specifične potrebe.

Kako upravljam ažuriranjima

Na prijenosnom računalu imam instalirana dva odvojena primjerka Git repo-a. Imam jedan za razvojne programere i jedan za produkcijski.

Koristim razvojno okruženje za, eto, razvoj! Prilično izravno. Proizvodnu mapu koristim isključivo u svrhu povlačenja ažuriranja iz Git master grane, pokretanja moje konfiguracije webpacka i postavljanja na produkcijski poslužitelj.

Razlog zbog kojeg su odvojeni je taj što mogu održavati zasebne konfiguracije elastičnog zrna graha i ne moram brinuti o postavljanju na pogrešno mjesto.

Ažuriranja koja ne zahtijevaju promjenu okoline Linux

Za ažuriranja koja ne zahtijevaju nikakve promjene u linux okruženju, to je jednostavno poput pokretanja eb deployu terminalu. Nevjerojatno je, a razmnožavanju treba oko 10 minuta.

Ažuriranja koja zahtijevaju promjenu okoline Linux

Povremeno ćete poželjeti ažurirati Linux okruženje, ali nećete moći i zato što je AWS jebeno glup (siguran sam da postoji razlog) i dopušta samo određene verzije Nodea na svakoj Linux izvedbi. Zbog toga je malo složenije, ali upravljivo.

  1. Pritisnite za konfiguraciju proizvodnje pod novom env. Posljednji put kad sam to učinio, upravo sam stvorio novu instancu putem eb create prod-1. Učinit će ono što treba i vašu će aplikaciju implementirati u novo okruženje.
  2. Provjerite rade li sva ažuriranja. Čini se prilično očitim, ali ovo je dobro vrijeme da provjerite nije li bilo štucanja s novom gradnjom.
  3. Provjerite jesu li vaša okruženja pravilno postavljena. Ovo je svojevrsni dio prethodne verzije, ali pripazite da povlačite iz pravog DB-a ili slično.
  4. Provjerite ima li vaš uravnoteživač opterećenja isti SSL cert (ako je primjenjiv). Zabavna činjenica, ako pokušate pristupiti ELB instanci u https-u bez certifikata, neće uspjeti!
  5. Zamijenite instance. Napokon, nakon što sve izgleda dobro, na konzoli se nalazi gumb za zamjenu URL-ova instance. LAKO MIRNO. U Route 53 ne morate ništa mijenjati, to sve čini umjesto vas.

Pa, eto vam. Kako upravljati ažuriranjima. Poprilično jednostavno.

Završne misli

Ako imate prijedloge kako to učiniti jeftinijim / lakšim, volio bih ih čuti. Sviđa mi se rasprava o alatima i opcijama jednako kao i sljedeći programer!

Uz to ću otići s ovim: Sretno kodiranje!