Реалността при изпълнението на производствено приложение Node на AWS Elastic Beanstalk

Уроци, научени от 2 години управление на производствено приложение Node на платформата ELB на AWS

Предна материя

Нека бъдем честни, калкулаторът на цените на AWS е объркващ. Част от това се дължи на а-ла-карт метода на плащане, който AWS предлага. Това затруднява опитите да се даде добра оферта на клиента. Надяваме се, че тази статия може да даде малко информация за това колко струва стартирането на приложение, както и някои начини за намаляване на разходите.

Реалните разходи за стартиране на приложение

Вече около две години управлявам уеб приложение на възел в ELB. Първата година беше страхотна, дадоха ви всичко безплатно (най-вече)! След това трябва да започнете да плащате за неща, като например EC2 инстанции.

Тази статия ще се съсредоточи върху конкретните ми изисквания за приложение, което е експресно приложение, базирано на възел, което се хоства на Elastic Beanstalk.

За пълни подробности относно компилацията вижте предишната ми статия тук.

Разбивка

Това е, което в момента работя на AWS:

Единична среда на EBS (Западен регион на САЩ):

  • 1 Класически балансиращ товар
  • 1 екземпляр t2.micro EC2
  • Кофа S3, която съхранява изображения (7 GB по време на писане)
  • 1 Маршрут 53 Хоствана зона

$ 18 (Балансир на товара) + $ 5 (EC2 с RI) + $ 0,50 (път 53) + $ 0,17 (S3) + $ 0,21 (Прехвърляне на данни) = Приблизително $ 25 на месец.

Освен това аз хоствам MongoDB другаде, така че ако планирате да хоствате DB на AWS, това ще доведе до допълнителни разходи. Нека разбием различните разходи.

Балансир на товара

Това е най-скъпата част от стека. Струва:

  • $ 0,025 за час на класически баланс на товара (или частичен час)
  • $ 0,008 на GB данни, обработени от класически балансиращ товар

Това означава, че ако стартирате приложението си 24 часа в денонощието, то ще струва приблизително $ 18 + такси за данни всеки месец.

Екземпляр EC2

Екземплярите EC2 при поискване са по-скъпи, отколкото би трябвало да бъдат. За да спестите малко пари тук, вижте раздела по-долу за Резервирани екземпляри на EC2. В случай, че се чудите, ще струва $ 8,40 за стартиране на същия тип EC2 екземпляр, както е споменато по-горе, при поискване.

S3

Имам няколко кофи S3. Един за статичната ми начална страница, един за задържане на изображения и един за задържане на версията на приложението. Доколкото знам, ELB автоматично създава тази за управление на версиите на приложенията.

S3 е доста евтин, така че не се притеснявам много да се опитвам да го никелирам, но има начини да спестите пари чрез тяхната система Glacier.

База данни

Аз хоствам моята MongoDB DB на mLab, която скоро изчезва. Така че ще актуализирам това, когато разбера колко всъщност ще струва, след като бъда принуден да се преместя в Атласа на Монго.

Резервирани екземпляри EC2

Нека поговорим за резервирани екземпляри (RI). Заплетената система за фактуриране на Amazon е най-объркващата част за управлението на каквото и да е в AWS. Резервираните екземпляри могат да облекчат част от разходите, но са твърде объркващи.

След много четене и разговори с обслужването на клиенти на AWS това разбрах.

Първо, има два различни начина, по които можете да резервирате къде е RI: Регионална зона и зона за наличност. Регионални средства, това е специфично за един от основните региони, напр. us-west-2 (Орегон). Зоната за наличност (AZ) е специфична за зона в този регион, например us-west-2 a (Орегон).

Купих RI в us-west-2 и той автоматично се приложи към моя екземпляр, работещ в тази област. Ако купите такъв в AZ, той ще важи само за конкретния AZ, например us-west-2a, така че ако ELB завърти екземпляр EC2 в us-west2b, ​​нямате късмет.

Освен това има „стандартни“ и „конвертируеми“ типове RI. Не съм на 100% какво означава това, но от това, което разбирам, кабриолетът е по-гъвкав за това, на което можете да го замените, но по-скъп.

И накрая, има три вида на плащанията: Няма предварително, частично предварително, всички предварително. Това е доста лесно, или не плащате нищо, някои или всички, когато резервирате екземпляра. Няма никаква полза от разходите, която виждам. Въпреки това, като нов акаунт, най-вероятно не можете да направите предварително.

Поддръжка на AWS:

Никакви предварително резервирани екземпляри (RI) не могат да представляват значителен риск от фактуриране за нови сметки, тъй като те са договорно задължение да плащат ежемесечно за целия срок на RI. Поради тази причина нови акаунти и слабо използвани акаунти не могат да се регистрират за No Upfront RIs, докато при нас не бъде изградена успешна история на таксуване.

Може да се сблъскате с тази грешка, ако се опитате да закупите непредплащане.

Грешка: Вашата текуща квота не ви позволява да закупите необходимия брой резервирани копия (Услуга: AmazonEC2; Код на състоянието: 400; Код на грешка: ReservedInscationsLimitExceeded;)

Предупреждение: По каквато и да е причина, отнема малко време на запазения екземпляр да започне, което означава, че първият ден от месеца винаги струва повече. Не съм сигурен защо е така, но ако разбера, ще актуализирам това. Вижте графиката по-долу:

Болкови точки

Това са само някои дребни оплаквания относно цялостната EBS, които според мен бих включил като допълнение към оригиналната си статия, в случай че сте любопитни.

Автоматичните актуализации всъщност не са толкова автоматични

Версиите на възлите не се подреждат от версия на версия.

Вижте стъпката по-долу за това как управлявам промяната на версиите на Linux, когато Node не работи.

Работа с повече от една среда

Наличието на среда за разработка и едновременно работещо производство е лесно, но е скъпо. Всъщност го удвоява. Затова обикновено унищожавам средата на разработчиците веднага щом приключа с нея.

Документацията е ужасяваща

AWS е твърде голям за свое собствено добро. Това е част от причината да пиша това. Беше наистина трудно да намеря отговори на конкретните си нужди.

Как управлявам актуализации

Имам два отделни екземпляра на моето Git репо, инсталирани на моя лаптоп. Имам един за разработчици и един за производство.

Използвам средата на разработчиците, за да се развивам! Доста директно. Използвам производствената папка единствено с цел изтегляне на актуализации от главния клон на Git, стартиране на конфигурацията на уеб пакета и внедряване на производствения сървър.

Причината да са отделни е, че мога да поддържам отделни еластични конфигурации на фасул и да не се притеснявам да се разположа на грешното място.

Актуализации, които не изискват промяна в средата на Linux

За актуализации, които не изискват промени в Linux средата, е толкова просто, колкото да стартирате eb deployв терминала. Удивително е и отнема около 10 минути за разпространение.

Актуализации, изискващи промяна в средата на Linux

Понякога ще искате да актуализирате средата на Linux, но също няма да можете, тъй като AWS е страшно тъпа (сигурен съм, че има причина) и позволява само определени версии на Node при всяка компилация на Linux. За това е малко по-сложно, но управляемо.

  1. Натиснете към производствената конфигурация под нов env. Последният път, когато направих това, току-що създадох нов екземпляр чрез eb create prod-1. Той ще направи това, от което се нуждае, и ще внедри приложението ви в нова среда.
  2. Уверете се, че всичките ви актуализации работят. Изглежда доста очевидно, но сега е подходящ момент да се уверите, че не е имало хълцане с новата версия.
  3. Уверете се, че env vars са настроени правилно. Това е някаква част от предишната версия, но се уверете, че дърпате от дясната DB или каквото и да било.
  4. Уверете се, че вашият балансиращ товар има същия SSL сертификат (ако е приложимо). Интересен факт е, че ако се опитате да получите достъп до екземпляр на ELB в https без сертификат, той няма да успее!
  5. Разменете копията. И накрая, след като всичко изглежда добре, има бутон в конзолата за смяна на URL адресите на екземпляра. ЛЕСНА РАБОТА. Не е нужно да променяте нищо в път 53, той прави всичко за вас.

И така, ето го. Как да управлявате актуализациите си. Доста лесно.

Финални мисли

Ако имате някакви предложения да го направите по-евтино / по-лесно, бих се радвал да ги чуя. Харесвам дискусията за инструменти и опции точно толкова, колкото следващия разработчик!

С това ще напусна с това: Честито кодиране!