A gyártási Node alkalmazás futtatásának valósága az AWS Elastic Beanstalk alkalmazáson

2 év tanulságai a termelési Node alkalmazás futtatásáról az AWS ELB platformján

Első anyag

Legyünk őszinték, az AWS árkalkulátor zavaró. Ennek része az AWS által kínált a la carte fizetési módszer. Ez megnehezíti a próbálkozást, hogy jó ajánlatot adjon egy ügyfélnek. Remélhetőleg ez a cikk megvilágíthatja, mennyibe kerül egy alkalmazás futtatása, valamint néhány módot a költségek csökkentésére.

Az alkalmazás futtatásának valós költségei

Körülbelül két éve kezelek egy csomópontos webalkalmazást az ELB-n. Az első év nagyon jó volt, mindent ingyen adtak (főleg)! Ezt követően el kell kezdenie fizetni a dolgokat, például az EC2 példányokat.

Ez a cikk az egyedi alkalmazáskövetelményeimre összpontosít, amely egy csomópont alapú expressz alkalmazás, amelyet az Elastic Beanstalk tárol.

Az összeállítással kapcsolatos részletekért lásd itt az előző cikkemet.

Bontás

Most éppen ezt futtatom az AWS-en:

Egységes EBS-környezet (USA nyugati régiója):

  • 1 klasszikus terheléselosztó
  • 1 t2.mikro EC2 példány
  • Képeket tároló S3 vödör (7 GB az írás idején)
  • 1 53-as út hostolt zónája

18 USD (terheléselosztó) + 5 USD (EC2 RI-vel) + 0,50 USD (53-as út) + 0,17 USD (S3) + 0,21 USD (adatátvitel) = Nagyjából 25 USD havonta.

Ezenkívül egy MongoDB-t is üzemeltetek máshol, így ha egy DB-t szeretne AWS-en tárolni, az további költségekkel jár. Bontjuk le a különféle költségeket.

Terhelés elosztó

Ez a verem legdrágább része. Ára:

  • 0,025 USD / klasszikus terheléselosztó-óra (vagy részóra)
  • 0,008 USD / GB a klasszikus terheléselosztó által feldolgozott adatokon

Ez azt jelenti, hogy ha az alkalmazást a nap 24 órájában futtatja, akkor ez havonta nagyjából 18 USD + adatköltségekbe fog kerülni.

EC2 példány

Az On-Demand EC2 példányok drágábbak, mint kellene. Ha pénzt szeretne megtakarítani, olvassa el az alábbi részt a Foglalt EC2 példányokról. Abban az esetben, ha kíváncsi lennél, 8,40 dollárba kerülne a fent említett EC2-példány futtatása igény szerint.

S3

Van egy pár S3 vödröm. Az egyik a statikus honlapomhoz, egy a képek és egy az alkalmazás verziójának tárolásához. Ha jól tudom, az ELB automatikusan létrehozza az alkalmazási verziók kezelésére szolgálót.

Az S3 elég olcsó, ezért nem aggódom amiatt, hogy megpróbálom nikkelezni és dimetilizálni, de a Glacier rendszerükön keresztül lehet pénzt megtakarítani.

Adatbázis

A MongoDB DB-t az mlab-ban tárolom, ami hamarosan megszűnik. Tehát frissíteni fogom ezt, amikor megtudom, mennyibe kerül valójában, ha kénytelen vagyok áttérni a Mongo atlaszára.

Foglalt EC2 példányok

Beszéljünk a lefoglalt példányokról (RI). Az Amazon összevissza számlázási rendszere a legzavaróbb rész az AWS-en bármi kezelésében. A lefoglalt példányok enyhíthetnek bizonyos költségeket, de túl zavarosak.

Sok olvasás és beszélgetés után az AWS ügyfélszolgálatával ezt sorta találtam ki.

Először is kétféle módon foglalhat helyet, ahol az RI található: Regionális és rendelkezésre állási zóna. Regionális eszközök, az egyik fő régióra jellemző, pl. us-nyugat-2 (Oregon). A rendelkezésre álló terület (AZ) csak egy bizonyos terület régión belül, pl nekünk irányban-2 a (Oregon).

Vettem egy RI-t bennünk-nyugat-2-en belül, és automatikusan alkalmaztam az adott területen futó példányomra. Ha az AZ-n belül vásárol egyet, az csak az adott AZ-ra vonatkozik, pl. Us-west-2a, tehát ha az ELB egy EC2 példányt forog fel bennünk-west2b, ​​akkor nincs szerencséje.

Ezenkívül léteznek „standard” és „átalakítható” típusú RI-k. Nem vagyok 100% -osan abban, hogy ez mit jelent, de abból, amit megértek, a kabrió rugalmasabb, mire lehet cserélni, de drágább.

Végül háromféle fizetési mód létezik: Nincs elöl, részlegesen elöl, Teljesen elöl. Ez meglehetősen egyszerű: vagy nem fizet semmit, részben vagy egészben, amikor lefoglalja a példányt. Nincs költség-haszon, amit látok. Új fiókként azonban valószínűleg nem tehet előre.

AWS támogatásonként:

Nincsenek előre lefoglalt példányok (RI-k), amelyek jelentős számlázási kockázatot jelenthetnek az új számlák számára, mivel szerződéses kötelezettséget jelentenek arra, hogy havonta fizessenek az RI teljes időtartama alatt. Emiatt az új számlák és a kevéssé használt fiókok nem tudnak regisztrálni a No Upfront RI-re, amíg sikeres számlázási előzményeket nem építenek fel velünk.

Előfordulhat, hogy belefut ebbe a hibába, ha nem előre vásárol.

Hiba: A jelenlegi kvóta nem teszi lehetővé a szükséges számú lefoglalt példány megvásárlását (Szolgáltatás: AmazonEC2; Állapotkód: 400; Hibakód: ReservedInstancesLimitExceeded;)

Figyelem: Bármilyen okból kifolyólag egy kis időbe telik, amíg a fenntartott példány „beindul”, ami azt jelenti, hogy a hónap első napja mindig többe kerül. Nem tudom, miért van ez, de ha rájövök, frissítem. Lásd az alábbi grafikont:

Fájdalom

Ez csak néhány apróbb panasz a teljes EBS-ről, amelyet úgy gondoltam, hogy kiegészítenék az eredeti cikkemhez, hátha kíváncsi vagy.

Az automatikus frissítések nem igazán olyan automatikusak

A csomópont verziók verzióról verzióra nem sorakoznak.

Lásd az alábbi lépést arról, hogy miként kezelhetem a Linux verzióinak megváltoztatását, ha a Node nem működik.

Több környezet futtatása

A fejlesztői környezet és a termelés egyidejű működtetése egyszerű, de drága. Valójában megduplázza. Ezért általában elpusztítom a dev környezetet, amint végzek vele.

A dokumentáció borzalmas

Az AWS túl nagy a saját érdekében. Ez az oka annak, hogy ezt írom. Nagyon nehéz volt választ találni a sajátos igényeimre.

Hogyan kezelem a Frissítéseket

Két külön példány van telepítve a laptopomra a Git repóval. Van egy a fejlesztőknek és egy a gyártáshoz.

A dev környezetet azért használom, hogy fejlődjek! Elég egyértelmű. Az éles mappát kizárólag abból a célból használom, hogy frissítéseket szerezzek a Git master fiókjából, futtassam a webcsomag-konfigurációmat és telepítsem a termelési kiszolgálóra.

Azért vannak külön azért, mert külön rugalmas rugalmas babkonzerv-konfigurációkat tudok fenntartani, és nem kell attól tartanom, hogy rossz helyre telepítem.

Olyan frissítések, amelyek nem igényelnek Linux környezeti változást

A linuxos környezet módosítását nem igénylő frissítésekhez olyan egyszerű, mint eb deploya terminálon történő futtatáshoz . Elképesztő, és a terjedése körülbelül 10 percet vesz igénybe.

Linux környezeti változást igénylő frissítések

Esetenként frissíteni szeretné a Linux környezetet, de nem lesz képes, mivel az AWS hülye (biztos vagyok benne, hogy van rá oka), és csak a Node bizonyos verzióit engedélyezi minden egyes Linux buildnél. Ehhez egy kicsit bonyolultabb, de kezelhető.

  1. Nyomja meg a gyártási konfigurációt az új env alatt. Az utolsó alkalommal csináltam ezt, én csak létrehozott egy új példány keresztül eb create prod-1. Megteszi, amire szüksége van, és új környezetbe telepíti az alkalmazást.
  2. Győződjön meg arról, hogy minden frissítése működik. Elég nyilvánvalónak tűnik, de ez egy jó alkalom arra, hogy megbizonyosodjon arról, hogy az új felépítés nem tartalmaz csuklást.
  3. Győződjön meg arról, hogy az env-változatait megfelelően állította be. Ez az előző verzió sorta része, de győződjön meg arról, hogy a megfelelő DB-ről vagy bármi másról van szó.
  4. Győződjön meg arról, hogy a terheléselosztó ugyanazzal az SSL-tanúsítvánnyal rendelkezik (ha van ilyen). Szórakoztató tény, ha tanúsítvány nélkül megpróbálsz elérni egy ELB példányt a https-ben, akkor ez nem fog sikerülni!
  5. Cserélje le a példányokat. Végül, miután minden rendben van, van egy gomb a konzolon, amely felcseréli a példány URL-jeit. KÖNNYEN BÉKE. Az 53-as úton semmit sem kell változtatnia, mindezt helyetted teszi.

Szóval, itt van. A frissítések kezelése. Elég könnyű.

Végső gondolatok

Ha bármilyen javaslata van, hogy olcsóbbá / könnyebbé tegye, szívesen meghallgatom őket. Ugyanúgy szeretem az eszközökről és lehetőségekről szóló vitát, mint a következő fejlesztőnek!

Ezzel távozom ezzel: Boldog kódolás!